[SISTEMA] A proposito di filesystem... (ext4, xfs, btrfs)

[andrea.paiola]

Originariamente inviato da taylorella
1) Ext4. Pro: è veloce, più veloce di ext3 (confermo). Contro: ogni tanto perde pezzi. (non ti confermo e spero di non farlo mai). Domanda: avendo ext4 per il sistema, che rischi corro? Che tipo un'installazione si incastri perchè si perde pezzi di file? Secondo te il fatto che Google lo abbia usato nei suoi server è significativo dell'affidabilità o anche no?

guarda, è successo un casino su ubuntu 10.04.1 ext4 giusto un paio di settimane fa, riportato su un altro forum... si era spento il pc e gli dava DBus error org.gtk.Private.RemoteVolumeMonitor.Failed:An operation is already pending quando cercava di aprirlo da una live

facendo check del disco da gparted gli da l'errore
"Filesystem mounted or opened exclusively by another program"

[bereshit]

il problema che alcuni programmi non gestivano bene il nuovo modo di scrittura di ext4

poi è stata scritta una patch per il kernel che risolveva ilo problema un pò a scapito delle prestazioni, red hat ed ubuntu usano questa patch di default

qui per chiarire

For Ts'o, the problem lies with application developers who take the forgiving behaviour of Ext3 to be a standard. He advises that, if an application wants to ensure that data have actually been written to disk, it must call the the function fsync() before closing the file. Nevertheless, as a workaround, he very quickly wrote patches for Ext4 that recognise the rename() situation and ensure it behaves like Ext3, and a second procedure that uses ftruncate(). Now, however, he has provided a "proper" solution. The new ext4 mounting option "alloc_on_commit" gives Ext4 a mechanism analogous to "data=ordered" in Ext3, whereby metadata is not committed in the journal until after blocks have been allocated and the data has been written. However, this change probably won't arrive until version 2.6.30 of the kernel at the earliest.

[taylorella]

Ma che bello leggere ste cose...sapevo che da sto thread sarebbero uscite cose interessanti!
Io in ogni caso sto usando Ubuntu con kernel 2.6.35-23 generic, quindi non dovrei avere di ste rogne, certo è che non mi pare proprio il massimo della vita avere un filesystem riconosciuto come "maturo" o "stable" che dir si voglia, usato di default nella distro, e poi trovarsi con ste magagne...

Io intanto sono andato avanti a leggere benchmark, recensioni e cose varie, e ho scoperto che:

1) JFS utilizza poca cpu, mediamente meno degli altri, però non ha tool di deframmentazione e come già detto da Paolino è fuori sviluppo da molto tempo.

2) XFS è modificabile in fase di creazione (e fin qui vabbè) ma in particolare aumentando la dimensione del file di log (da 22 MB standard a 32-64-128 MB) e aumentando il numero di allocation group (una caratteristica di XFS che porta a parallelizzare il lavoro), nonchè portando a 8 il numero di log buffers in fase di montaggio si possono raggiungere prestazioni più che apprezzabili, paragonabili a ext3 per quanto riguarda la cancellazione, ma migliori di ext3 per quanto riguarda altri parametri, come la velocità di mount/unmount, l'utilizzo di cpu e altre cose viste nei bench.
Il mio XFS è già "tweakkato", includendo queste caratteristiche, però non ricordavo che bastasse modificare questi tre parametri, mi pareva servisse molta più roba.
Unico "inconveniente" per l'utente novello: tutte ste belle cose vanno fatte con "mkfs.xfs", altrimenti si rischia di incappare in casini se si usa tipo Gparted et similia, ma comunque non è niente di che: -d agcount=XX per specificare il numero di gruppi di allocazione e -l size=XXm per specificare il numero di mega del file di log. Basta.
Non ho ben capito quanti allocation groups vanno scelti (ovvero che relazione deve esserci tra giga in gioco e allocation groups) nè quanto grande deve essere il log (32, 64, 128, 256..?), comunque penso che cercando meglio in Google, magari con keywords in inglese, si riesca anche a scoprire.

3) Molta gente è "alterata" per comportamenti inconsulti di ext4, anche se i problemi più grossi li ho trovati in discussioni in cui si parlava di /home, piuttosto che di / . Per il momento questo è quanto ho trovato io, ovviamente non sapevo dei casini con Google, ne di quelli nominati da Bereshit e Andrea...

[alexmaz]

Quando si parla di queste cose bisogna stare attenti alle opinioni non basate su fatti e ai rumors buttati li senza contestualizzazione. Il problema a cui si riferisce Paiola potrebbe o non potrebbe essere imputabile a ext4 perchè alla persona in questione si è spento il pc per un problema hardware e non per mancanza di corrente. A me il pc si è spento per mancanza di corrente mentre ext4 scriveva e non ho avuto problemi. La caratteristica di ext4 su cui tutti puntano il dito si chiama delayed allocation, ossia la scrittura effettiva dei dati viene ritardata il più possibile per aumentare le prestazioni (detta in modo semplice, spiegazione migliore http://en.wikipedia.org/wiki/Allocate-on-flush ). Rullo di tamburi, questa caratteristica è presente anche in altri filesystem, btrfs, hfs+ (Mac Os x), XFS e ZFS. Quello che ha creato problemi con ext4 è che molti programmatori di applicazioni facevano affidamento sul comportamento di ext3 (sbagliando) e quando la "massa" è passata a ext4 si sono verificati problemi (forse anche per un'implementazione particolarmente aggressiva di questa caratteristica). Il problema si sarebbe verificato anche con xfs o altro filesystem che facesse uso della delayed allocation, solo che questi filesystem o non sono presenti in linux (zfs, hfs+) , o sono in fase sperimentale e quindi poco usati (btrfs) oppure sono solo poco usati perchè all'utente medio, anche di linux, non frega quasi mai nulla di cambiare filesystem di default perchè la differenza di prestazione è marginale, è il caso di xfs.

[andrea.paiola]

verissimo quello che scrive alexmaz, il mio mica era un post molto serio eh

[Bifrost]

3) BTRFS: è promettente, ma è un suicidio usarlo adesso, ergo ho fatto bene a non usarlo per il sistema. Resti dell'idea "suicidio" nonostante Canonical lo abbia messo tra le scelte di Ubuntu in fase di installazione? francamente io non so chi prenda le decisioni in Canonical e non capisco nemmeno perchè meego la abbia adottato di default con l'attuale release

uhmmm... beta tester ingnari?

[taylorella]

Originariamente inviato da alexmaz
Quando si parla di queste cose bisogna stare attenti alle opinioni non basate su fatti e ai rumors buttati li senza contestualizzazione. Il problema a cui si riferisce Paiola potrebbe o non potrebbe essere imputabile a ext4 perchè alla persona in questione si è spento il pc per un problema hardware e non per mancanza di corrente. A me il pc si è spento per mancanza di corrente mentre ext4 scriveva e non ho avuto problemi. La caratteristica di ext4 su cui tutti puntano il dito si chiama delayed allocation, ossia la scrittura effettiva dei dati viene ritardata il più possibile per aumentare le prestazioni (detta in modo semplice, spiegazione migliore http://en.wikipedia.org/wiki/Allocate-on-flush ). Rullo di tamburi, questa caratteristica è presente anche in altri filesystem, btrfs, hfs+ (Mac Os x), XFS e ZFS. Quello che ha creato problemi con ext4 è che molti programmatori di applicazioni facevano affidamento sul comportamento di ext3 (sbagliando) e quando la "massa" è passata a ext4 si sono verificati problemi (forse anche per un'implementazione particolarmente aggressiva di questa caratteristica). Il problema si sarebbe verificato anche con xfs o altro filesystem che facesse uso della delayed allocation, solo che questi filesystem o non sono presenti in linux (zfs, hfs+) , o sono in fase sperimentale e quindi poco usati (btrfs) oppure sono solo poco usati perchè all'utente medio, anche di linux, non frega quasi mai nulla di cambiare filesystem di default perchè la differenza di prestazione è marginale, è il caso di xfs.

Questa cosa è molto interessante, quindi in definitiva ext4 sopporta bene anche le batoste di power off violento, e ciò è bene. Sulla differenza di prestazioni marginale ne sei così sicuro?
Cioè, secondo te usare ext3, ext4, xfs o btrfs è pressochè uguale in quanto a prestazioni misurate nei termini di cpu load, velocità di trasferimento, velocità di boot ecc? Chiedo, perchè io ho notato delle differenze tangibili (decine di secondi su operazioni da un minuto, metti caso) sopratutto con xfs e ext4...

[Meskalamdug]

Io con Ext4 ci ho messo su un LVM2 su Slackware current
,dati persi neppure 1.

[taylorella]

Buono a sapersi, ora non resta che capire com'è sto Btrfs, ma mi sa che è un po'una causa persa, perchè penso nessuno lo usi.
Ma...solo a me piace un sacco XFS?
Non so, mi pare un gran filesystem, però pare che non gliene freghi nulla a nessuno di usarlo...boh...

[alexmaz]

Se guardi i test dei vari fs su phronix, vedi che xfs raramente va meglio di ext4, o forse mai, non ricordo. btrfs nelle ultime due versioni del kernel è precipitato in prestazioni, ma d'altra parte è codice ancora pesantemente sviluppato. In generale io non ho mai visto differenze apprezzabili anche perchè faccio un uso abbastanza generico del pc, no file enormi, no grande numero di file piccoli, o roba strana. Le differenze di boot mi paiono strane, a parità di sistema, tutto uguale tranne il filesystem hai visto grosse differenze? In fase di boot carichi si e no 400 mb da disco in ram, mi pare dura vedere differenze abissali. Io xfs lo uso solo su un server su cui ho il db del gestionale su amazon ec2 perchè ho trovato un tool per fare degli snapshot coerenti usando il freeze di xfs (anche ext3/ext4 da un po' di tempo sono frezzabili ma non ho trovato nulla).