Komprimierte Filesystme heute oft schneller

[YPenguin]

Es mag komisch klingen, aber mit den heutigen Prozessorleistungen können komprimierte Filesysteme nicht nur schneller sein, sondern sind es sogar meist in der Praxis. Dies gilt insbesondere für den Lesezugriff.
Meine Erfahrungen stammen von NTFS sowohl mit Festplatten (Seagate) als auch SSDs (Samsung).
Bei SSDs sollte man beachten, dass manche einen Sandforce-Controller haben, der die Daten komprimiert - solche SSDs brauchen eine gesonderte Betrachtung. Ich hab sie deshalb bislang gemieden.

[ChrisJumper]

Hi YPenguin,

ist dir das nur bei NTFS begegnet oder auch bei BTRFS und Co?

Bisher habe ich aus "Stabilitätsgründen", eigentlich nur ext4 verwendet. Doch hier im Forum liest man auch schon das viele BTRFS verwenden.

Jetzt wo die SSDs so im Preis gefallen sind, überlege ich ernsthaft einige Platten günstig auszutauschen und dann wäre ein Wechsel von ext4 zu BTRFS ja interessant.

Was habt ihr so in Verwendung und wie sind eure Erfahrungen?
Hattet ihr schon Datenverlust oder Korrupte Installtionen/Datenbanken wegen "BETA-File-Systemen"?

Zum Schluss noch eine Frage aus der Kategorie: Was ich mich nie getraut habe zu fragen.
Bezüglich eines Netzwerk-Dateisystemes, das müsste doch schneller und effizienter sein als Binärdateien (Binary Blobs) in einer Datenbank.
Mich wundert es immer wenn diverse Webanwendungen das aber so machen. Sicher sie verwalten die Zugriffskontrolle anders, aber da wird es doch noch mehr geben oder?
Ein wenig sind bei einer Datenbank-Datei ja auch zwei Schichten auf einander, da die Datenbank in der Regel ja auch auf einem File-System liegt und nur ganz selten permanent im RAM oder FLASH-Speicher.

Grüße

Chris

[toralf]

Ich habe auf meinem KDE Desktop BTRFS seit

Code: Select all

1417968809: Started emerge on: Dec 07, 2014 16:13:29

als einziges FS. Daneben habe ich auf der Tinderbox [1] seit ca. 3 Jahren zwei LVs als Datenpartitionen (je 2.3 TB), welche auf 2 HDDs ge-striped angelegt sind. Dort ist auch entsprechend I/O Traffic drauf, auf dem Desktop eher das Übliche rumge-Git-te.

Bis jetzt läuft alles zufriedenstellend - nutze auch immer den aktuellsten Vanilla stable Kernel.

[1] https://zwiebeltoralf.de/tinderbox.html

[mv]

Ich habe zwar keine Erfahrung mit btrfs und zfs, aber gehört, dass beide bei vollen Partitionen Ärger machen ("disk full"-Meldungen beim Schreiben, obwohl Platz da wäre, weil Garbage collection noch nicht da war usw., im Fall von btrfs z.T. auch Datenverluste). Da meine Partitionen regelmäßig übervoll sind, sehe ich nicht, dass ich in näherer Zukunft wechseln könnte.
Für Kompression benutze ich lieber squashfs+overlay für spezielle Directories, bei denen sich das lohnt.

[doedel]

Jetzt wo die SSDs so im Preis gefallen sind, überlege ich ernsthaft einige Platten günstig auszutauschen und dann wäre ein Wechsel von ext4 zu BTRFS ja interessant.

Für was sollen denn die SSDs verwendet werden? Ich habe persönlich noch bedenken, Datenspeicher-Platten gegen SSDs zu tauschen, denn wenn die ausfallen, ist von jetzt auf gleich die SSD einfach tot.
Trotz Backups habe ich es gern, dass ich im Fall des Falles eine Datenrettung anstrengen könnte. Die Backups mache ich auch nicht unbedingt täglich.
Wenn Platten irgendwann aufgeben, kommt das meist schleichend mit Anzeichen und man kann noch schnell auf eine andere migrieren.

Im Laptop und im Arbeitsrechner habe ich schon vor langem auf SSDs umgestellt. Die USB-Platten und Datenspeicher-Platten bleiben jedoch bis auf Weiteres Festplatten.

[firefly]

Ich habe persönlich noch bedenken, Datenspeicher-Platten gegen SSDs zu tauschen, denn wenn die ausfallen, ist von jetzt auf gleich die SSD einfach tot.

Das gleiche hast du auch bei HDDs, wenn die Ausfällt dann ist die HDD auch tot. Also das ist kein Grund gegen SSD.

[doedel]

Bisher haben alle Platten, die bei mir kaputt gingen angefangen Probleme zu machen und sind dann erst ausgestiegen - bzw flogen vor dem Aussteigen schon auf den Schrott.

Gerade im Moment kopiere ich Kram von einer 320GB Laptop Platte, die klackert und im syslog Fehlermeldungen auftauchen

Die einzige SSD, die bisher bei mir kaputt ging war neu und hat kurz nach der Garantie von Heute auf Morgen einfach gar nichts mehr gemacht.


Gerade aus meinem Syslog:
Nur eine Datei hat bisher nicht kopiert werden wollen.

Code: Select all

[22762.123086] ata1.00: exception Emask 0x0 SAct 0x7000000 SErr 0x0 action 0x0
[22762.123089] ata1.00: irq_stat 0x40000008
[22762.123093] ata1.00: failed command: READ FPDMA QUEUED
[22762.123100] ata1.00: cmd 60/00:c0:00:88:45/02:00:12:00:00/40 tag 24 ncq dma 262144 in
                        res 41/40:00:a5:89:45/00:00:12:00:00/40 Emask 0x409 (media error) <F>
[22762.123102] ata1.00: status: { DRDY ERR }
[22762.123104] ata1.00: error: { UNC }
[22762.127191] ata1.00: configured for UDMA/100
[22762.127227] sd 0:0:0:0: [sda] tag#24 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[22762.127231] sd 0:0:0:0: [sda] tag#24 Sense Key : Medium Error [current] 
[22762.127235] sd 0:0:0:0: [sda] tag#24 Add. Sense: Unrecovered read error - auto reallocate failed
[22762.127249] sd 0:0:0:0: [sda] tag#24 CDB: Read(10) 28 00 12 45 88 00 00 02 00 00
[22762.127252] print_req_error: I/O error, dev sda, sector 306547109
[22762.127317] ata1: EH complete
[22765.456339] ata1.00: exception Emask 0x0 SAct 0x2000002 SErr 0x0 action 0x0
[22765.456343] ata1.00: irq_stat 0x40000008
[22765.456356] ata1.00: failed command: READ FPDMA QUEUED
[22765.456363] ata1.00: cmd 60/08:c8:a0:89:45/00:00:12:00:00/40 tag 25 ncq dma 4096 in
                        res 41/40:00:a5:89:45/00:00:12:00:00/40 Emask 0x409 (media error) <F>
[22765.456365] ata1.00: status: { DRDY ERR }
[22765.456367] ata1.00: error: { UNC }
[22765.460260] ata1.00: configured for UDMA/100
[22765.460313] sd 0:0:0:0: [sda] tag#25 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[22765.460318] sd 0:0:0:0: [sda] tag#25 Sense Key : Medium Error [current] 
[22765.460322] sd 0:0:0:0: [sda] tag#25 Add. Sense: Unrecovered read error - auto reallocate failed
[22765.460327] sd 0:0:0:0: [sda] tag#25 CDB: Read(10) 28 00 12 45 89 a0 00 00 08 00
[22765.460331] print_req_error: I/O error, dev sda, sector 306547109
[22765.460395] ata1: EH complete
[22769.269796] ata1.00: exception Emask 0x0 SAct 0x20000000 SErr 0x0 action 0x0
[22769.269799] ata1.00: irq_stat 0x40000008
[22769.269803] ata1.00: failed command: READ FPDMA QUEUED
[22769.269819] ata1.00: cmd 60/08:e8:a0:89:45/00:00:12:00:00/40 tag 29 ncq dma 4096 in
                        res 41/40:00:a5:89:45/00:00:12:00:00/40 Emask 0x409 (media error) <F>
[22769.269821] ata1.00: status: { DRDY ERR }
[22769.269823] ata1.00: error: { UNC }
[22769.274169] ata1.00: configured for UDMA/100
[22769.274198] sd 0:0:0:0: [sda] tag#29 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[22769.274203] sd 0:0:0:0: [sda] tag#29 Sense Key : Medium Error [current] 
[22769.274207] sd 0:0:0:0: [sda] tag#29 Add. Sense: Unrecovered read error - auto reallocate failed
[22769.274212] sd 0:0:0:0: [sda] tag#29 CDB: Read(10) 28 00 12 45 89 a0 00 00 08 00
[22769.274215] print_req_error: I/O error, dev sda, sector 306547109
[22769.274268] ata1: EH complete

//edit:
In einem Bastelrechner läuft "nur so als Test, wie lang das gut geht" eine IBM Festplatte von 1999. Die lief bis vor drei Jahren in einem Server rund um die Uhr, dann kamen zwei Wochen Pause und ich mache da jetzt weiter.
Eigene Geräte hab ich leider nicht, die 20 Jahre durchlaufen, würde aber gern "dabei sein", wenn die stirbt.

[ChrisJumper]

Bisher ist mir noch keine SSD kaputt gegangen.

Normale rotierende Festplatten habe ich meistens immer durch eine größere Ersetzt, aber eher weil der Speicherplatz voll war. Zwei die ich dann noch für Backups brauchte oder unwichtige Daten, wurden sehr langsam oder hatten viele Bad-Blocks. Mit den smartmontools lässt sich nicht ablesen wann die Platte kaputt geht, aber du siehst wie viele Stunden die in Betrieb war, wie viele Raw_Read_Error_Rate, sie produzierte.

Auch lässt sich der Verschleiß halt beobachten.