November 2010 Archive

Die vier Ereignisse künden vom Backup-Error um 21:51:22.

Die Ausgaben der Ereignisse habe ich hier einmal aufgeführt:

1.) Event 8193

Protokollname: Application
Quelle:        VSS
Datum:         10.11.2010 21:51:25
Ereignis-ID:   8193
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      Powerplant.tobis-home.de
Beschreibung:
Volumeschattenkopie-Dienstfehler: Beim Aufrufen von Routine "IVssAsrWriterBackup::GetAsrMetadata" ist ein unerwarteter Fehler aufgetreten. hr = 0x80042416, Die Systempartition (als "aktiv" markierte Partition) ist versteckt oder enthält ein unbekanntes Dateisystem. Diese Konfiguration wird für Sicherungen nicht unterstützt.
.

Vorgang:
   PrepareForBackup-Ereignis

Kontext:
   Ausführungskontext: ASR Writer
   Ausführungskontext: Writer
   Generatorklassen-ID: {be000cbe-11fe-4426-9c58-531aa6355fc4}
   Generatorname: ASR Writer
   Generatorinstanz-ID: {2b66ed38-cb27-4d0c-ab43-e627131ed2ca}

Fehlerspezifische Details:
   ASR Writer: Die Systempartition (als "aktiv" markierte Partition) ist versteckt oder enthält ein unbekanntes Dateisystem. Diese Konfiguration wird für Sicherungen nicht unterstützt. (0x80042416)

2.) Event 12290

Protokollname: Application
Quelle:        VSS
Datum:         10.11.2010 21:51:25
Ereignis-ID:   12290
Aufgabenkategorie:Keine
Ebene:         Warnung
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      Powerplant.tobis-home.de
Beschreibung:
Volumeschattenkopie-Dienstwarnung: ASR writer Error 0x80042416. hr = 0x00000000, Der Vorgang wurde erfolgreich beendet.
.

Vorgang:
   PrepareForBackup-Ereignis

Kontext:
   Ausführungskontext: ASR Writer
   Ausführungskontext: Writer
   Generatorklassen-ID: {be000cbe-11fe-4426-9c58-531aa6355fc4}
   Generatorname: ASR Writer
   Generatorinstanz-ID: {2b66ed38-cb27-4d0c-ab43-e627131ed2ca}

Fehlerspezifische Details:
   ASR Writer: Die Systempartition (als "aktiv" markierte Partition) ist versteckt oder enthält ein unbekanntes Dateisystem. Diese Konfiguration wird für Sicherungen nicht unterstützt. (0x80042416)

3.) Event 16387

Protokollname: Application
Quelle:        SPP
Datum:         10.11.2010 21:51:25
Ereignis-ID:   16387
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      Powerplant.tobis-home.de
Beschreibung:
Fehler beim Erstellen von Schattenkopien, da ASR Writer einen Fehler gemeldet hat.  Weitere Informationen: Die Systempartition (als "aktiv" markierte Partition) ist versteckt oder enthält ein unbekanntes Dateisystem. Diese Konfiguration wird für Sicherungen nicht unterstützt. (0x80042416).

4.) Event 4100 (Windows Backup)

Protokollname: Application
Quelle:        Windows Backup
Datum:         10.11.2010 21:51:25
Ereignis-ID:   4100
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      Powerplant.tobis-home.de
Beschreibung:
Die Sicherung wurde nicht erfolgreich abgeschlossen, da eine Schattenkopie nicht erstellt werden konnte. Löschen Sie auf dem zu sichernden Laufwerk nicht benötigte Dateien, um Speicherplatz freizugeben, und wiederholen Sie den Vorgang.


Lösung:

Windows ist nur mein Zweit-Betriebssystem, daher läuft GRUB als Bootloader. Da ich kürzlich eine neue Festplatte eingebaut hatte, benutze ich nun die Neue als Bootlaufwerk. Der GRUB musste auch mit umziehen.

Nun ist es so, dass die neue Platte (SSD) im BIOS als 1. Bootplatte eingerichtet ist.
Windows und die Partition mit dem Windows-Bootloader sind auf dem "alten" RAID nur in zweiter Reihenfolge.

Das Backupsystem scheint also mit der Umstellung der 1. Bootplatte im BIOS ein Problem zu haben. Die Windows-System-Platte (bzw. Windows-Bootloader) müssen im BIOS an erster Bootreihenfolge stehen.

Ein Versuch gab mir Recht: Kurzerhand stellte ich die Windows-Platte im BIOS als HDD1 ein. Backup angeworfen: Läuft wieder ohne Fehler!

Glücklicherweise hatte ich die alte GRUB-Partition auf der Windows-Platte nicht gelöscht. GRUB und Windows-Backup schließen sich also nicht aus. Der GRUB muss nur auf dem gleiche Laufwerk wie der Windows-Bootloader (vielleicht auch Windows-System) liegen.

So, inzwischen ist das Backup beinahe fertig. Und ich überlege mir, ob ich meine alte GRUB-Partition auf dem Windows-RAID nicht wieder standardmäßig wegen den Win7-Backup-Bugs in Benuzung nehme.

resource_fetches: 0
total_page_load_ms: 0
page_load_count: 0
cache_extensions: 0
not_cacheable: 0
css_file_count_reduction: 0
css_filter_files_minified: 0
css_filter_minified_bytes_saved: 0
css_filter_parse_failures: 0
css_elements: 0
image_inline: 0
image_rewrite_saved_bytes: 0
image_rewrites: 0
javascript_blocks_minified: 0
javascript_bytes_saved: 0
javascript_minification_failures: 0
javascript_total_blocks: 0
url_trims: 0
url_trim_saved_bytes: 0
resource_404_count: 0
slurp_404_count: 0
serf_fetch_request_count: 0
serf_fetch_bytes_count: 0
serf_fetch_time_duration_ms: 0
serf_fetch_cancel_count: 0

$ sudo a2dismod pagespeed

Die Verzögerungen können sicherlich auch an meinem 1GHz-Server liegen, obwohl die Auslastungsdaten etwas anderes zeigen. Vielleicht ist der Kleine ja wirklich zu lahm für solch tolle Bandbreiteneinsparungen=Komprimierungen. Nur ist für mich fraglich, wie da die Verhältnismäßigkeiten sind. Brauche ich da viel Rechenpower um etwas Bandbreite einzusparen? Bringt das nur was, wenn viele Anfragen auf die einmal komprimerten Daten kommen? Was ist, wenn sich an meinem Output laufend was ändert? Oder ist der mod_pagespeed einfach nur total verbuggt?

Fragen über Fragen! ...is ja auch die beta-Version und vielleicht muss ich mich auch mehr in die Konfiguration einlesen - aber ich versuche es dann mal mit einer späteren Version aus. Danke Google!

Das Auspacken ist unspektakulär, schön für Desktopuser ist der mitgelieferte Einbaurahmen.

Der Einbau ist sicherlich auch keine Wunderleistung der Ingenieurkunst. Das 2.5"-Format lässt den benachbarten Platten noch schön viel Luft.
Nach dem Verstöpseln und dem mit Spannung erwarteten Erkennen des Laufwerks konnten die Tests beginnen.
Device Infos:

$ sudo smartctl -i /dev/sda
Device Model:     OCZ-VERTEX2
Serial Number:    OCZ-1600Y229CVXXXXXX
Firmware Version: 1.23
User Capacity:    120.034.123.776 bytes
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   8
ATA Standard is:  Not recognized. Minor revision code: 0x28
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Das Testen:

Hier seht ihr die Übersicht von Ubuntus Laufwerksverwaltung "palimpset".

Ein Klick auf den Button "Smart-Werte" brachte Folgendes zum Vorschein:



Nun gut, die SMART-Infos sind eher spärlich gesäht. Dieses System ist allerdings auch für sich bewegende Platten geschaffen und nicht für mein neu erstandenes Festkörperlaufwerk ;o)

Die Geschwindigkeitswerte im RAW-Mode sind erstaunlich. Ohne Formatieren bzw. Partitionieren geht's da richtig ab. Die Herstellerangaben werden sogar beinahe eingehalten.


Nach dieser Aktion ging ich über, mit meinem Ubuntu "Lucid Lynx" mal flugs auf die SSD umzuziehen.

Die Partitionierung sollte man möglich knauserig vornehmen. Ich gönnte mir eine 500MB Boot-Partition. Den Rest der 120GB packte ich in eine root-partition. Den Speicherbereich für Auslagerungsdaten sollte man von einer SSD fernhalten. Die Swap-Partition blieb auf meinem RAID-System. Mit einer Live-CD machte ich eine Kopie meines Produktivsystems einschließlich meines /home-Verzeichnisses. Die Boot-Partition wurde mit dem Befehl grub-install (hier nachzulesen) gefüllt und aktiviert.

Ein erfolgreiches Booten war Pflicht, um einen Speedtest an der laufenden Installation durchzuführen:

Hier sind nun schon einige Unterschiede zum RAW-Test zu erkennen. Allein die mittleren Zugriffszeiten streuen jetzt nicht mehr so stark (man beachte den anderen Maßstab), sind aber im Mittel jetzt bei 0.2 ms. Die Leserate ist deutlich abgesackt.

Die Tests im laufenden Betrieb streuen etwas. Ein späterer Test, mit ausgewählt besseren Werten, ist hier zu sehen:

Wie Euch in der Übersicht der Speichergeräte vielleicht nicht entgangen ist, habe ich auch noch zwei Vergleichslaufwerke im Rechner eingebaut. Im rein synthetischen Vergleich der Speedtests mit den Platten meines Hardware-Raid-Controllers (3ware 9650SE-4LP), ist die SSD klar überlegen.... aber seht selbst:

RAID-0 mit 2x1TB Samsung@7200rpm (Standard Desktop Platten): Device Info
$ sudo smartctl -i --device=3ware,0 /dev/twa0
Device Model:     SAMSUNG HD103UJ
Serial Number:    S13PJXXXXXXXXX
Firmware Version: 1AA01113
User Capacity:    1.000.204.886.016 bytes
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   8
ATA Standard is:  ATA-8-ACS revision 3b

$ sudo smartctl -i --device=3ware,1 /dev/twa0
Device Model:     SAMSUNG HD103UJ
Serial Number:    S13PJ1XXXXXXXX
Firmware Version: 1AA01113
User Capacity:    1.000.204.886.016 bytes
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   8
ATA Standard is:  ATA-8-ACS revision 3b

RAID-0 2x2TB Western Digital@5400rpm (Server Platten): Device Info
$ sudo smartctl -i --device=3ware,2 /dev/twa0
Device Model:     WDC WD2002FYPS-01U1B1
Serial Number:    WD-WCAVY15XXXXX
Firmware Version: 04.05G05
User Capacity:    2.000.398.934.016 bytes
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   8
ATA Standard is:  Exact ATA specification draft version not indicated

$ sudo smartctl -i --device=3ware,3 /dev/twa0
Device Model:     WDC WD2002FYPS-01U1B1
Serial Number:    WD-WCAVY15XXXXX
Firmware Version: 04.05G05
User Capacity:    2.000.398.934.016 bytes
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   8
ATA Standard is:  Exact ATA specification draft version not indicated

Deutlich zu erkennen, dass der interne Speicher (cache) der Serverplatten beim Ergebnis hin und wieder ordentlich reinhaut. Die Samsung-Desktopplatten zeigen diesen Effekt nicht. Daher muss davon ausgehen, dass der RAID-Controller nicht Schuld ist.

Der Cache bringt insbesondere den Serverplatten nur einen kurzen Schub, deshalb kann man die maximalen Lesegeschwindigkeiten getrost ausklammern. Der Effekt ist zwar da, ich kann aber nur schwer einschätzen ob er etwas bringt.

Interessant am letzten Teil meines SSD-Berichts ist eigentlich der direkte Plattenvergleich 7200 vs. 5400 rpm (Umdrehungen/min). Die SSD ist den Werten nach deutlich vorn.

HDPARM-Test:

$ sudo hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   8482 MB in  2.00 seconds = 4243.98 MB/sec
 Timing buffered disk reads:  404 MB in  3.01 seconds = 134.12 MB/sec

$ sudo hdparm -tT /dev/sdb

/dev/sdb:
 Timing cached reads:   8886 MB in  2.00 seconds = 4446.25 MB/sec
 Timing buffered disk reads:  674 MB in  3.00 seconds = 224.48 MB/sec

$ sudo hdparm -tT /dev/sdc

/dev/sdc:
 Timing cached reads:   9036 MB in  2.00 seconds = 4521.76 MB/sec
 Timing buffered disk reads:  650 MB in  3.00 seconds = 216.32 MB/sec


So, nun könnt ihr mal raten, welche Platte(n) sda sdb oder sdc sind.

Das Ausschlusskriterium gibt Euch Recht. SDA muss mein neues Festkörperlaufwerk sein. Ist So: Hier spielen die Buffer des 3ware-RAID-Controllers wohl ihre Stärken aus.


Subjektive Beurteilung:

Der gefühlte Geschwindigkeitsgewinn ist lediglich beim Programmstart auszumachen. Beim Booten spielt offenbar der CPU auch noch eine wichtige Rolle bzw. ist der Datendurchsatz der SSD im Vergleich zum Hardware-RAID-0 nicht allzu viel höher.

Ubuntu hat mit dem Samsung-RAID in ca. 23s bis zum Login gebootet. Die SSD braucht nun ca. 20s.

Die Festplatten (raid) gingen vor allem bei einem Parallelstart von virtuellen Maschinen in die Knie. Ein gleichzeitiger Start von Ubuntu und Windows hatte ein längeres Warten zur Konsequenz. Mit der SSD ist dieser Zustand Geschichte. GIMP oder Firefox sind prompt da. Nach dem Login bis zum "fertigen" Desktop geht es spürbar schneller. Der Geschwindigkeitsgewinn ist schon spürbar.

Fazit:

Die Anschaffung hat sich für mich schon gelohnt. Wer allerdings mehr Wert auf viel Speicherplatz legt, sollte lieber in einen vernünftigen Hardware-RAID-Controller investieren.

Beim Kopieren von großen Datenvolumen sind sicherlich die RAID-Laufwerke die Bremse, jedoch kann ich auf diese nur große Daten kopieren. Die Kopiererei von SSD zu SSD wäre sicherlich schneller. Aber bisher sind die größeren Exemplare dieser Gattung unerschwinglich und meiner Meinung nach auch unnötig, da der Vorteil einer SSD im Vergleich zu einem vernünftigen RAID-System nur in Extremsituationen merkbar ist. Schlichtweg im Desktop-Rechner eine Sache für Nerds... im Mobilbereich bestimmt eine Revolution.

Update:

Letzlich kopierte ich eine 5,5GB große Datei von meinem Desktop (Festkörperlaufwerk) auf eine raid-Partition. Die Übertragungsrate pendelte sich so bei 70-80MB/s ein: Das kann doch nicht sein, dachte ich. Ein nachfolgender Test von raid-zu-raid war etwa doppelt so schnell. (Hab's leider nicht dokumentiert.)

Das veranlasste mich zu einem erneuten Test mit der gleichen Datei, wobei ich die Werte leider nicht reproduzieren konnte. Eventuell lief da noch etwas im Hintergrund. Trotzdem sehr interessant.

Dateisysteme bei allen Laufwerken sind: ext4

(Ist klar: Der Balken symbolisiert lediglich den Kopierfortschritt!)

Festkörperlaufwerk (Desktop) ==> WD-Raid@5400rpm (raidstor)

Festkörperlaufwerk (Desktop) ==> Samsung-Raid@7200rpm (Videos)

WD-Raid@5400rpm (raidstor) ==> Festkörperlaufwerk (Desktop)

WD-Raid@5400rpm (raidstor) ==> Samsung-Raid@7200rpm (Videos)

Samsung-Raid@7200rpm (Videos) ==> Festkörperlaufwerk (Desktop)

Samsung-Raid@7200rpm (Videos) ==> WD-Raid@5400rpm (raidstor)

Naja, ich brauche da nicht zu viel Worte zu verlieren, hier ist eine Übersichtstabelle.

Quelle  /  Ziel                  SSD            WD-Raid           Samsung-Raid

SSD                             ----------           144 MB/s           140 MB/s

WD-Raid                      93 MB/s           -----------             145 MB/s

Samsung-RAID            96 MB/s          135 MB/s             -----------