Ext2 e Ext3 soppiantati da Ext4?

[Pare]

Un piccolo dubbietto...
Se non ho capito male si possono montare come ext4 tutti i filesystem precedenti (ext2 e ext3) e, se non applico funzionalità strane (con un tune2fs -O qualchenuovaopzione /dev/device), i filesystem cosi' montati, utilizzati e rismontati sono ancora compatibili con ext2/3.
Quindi questo significa che se voglio utilizzare ext4, compilandomelo quindi nel kernel (o caricando i moduli relativi) non ho nessuna ragione per compilarmi (o caricare i moduli) anche ext2 e ext3...
Sbaglio? Voi vedete qualche controindicazione ad avere solo ext4 disponibile nel kernel?

[HoX]

Premetto che potrei sbagliarmi!
Secondo me la compilazione di ext4 implica la compilazione degli altri 2. Gia' solo da ext2 ad ext3 la differenza maggiore era data da un #ifdef ... #endif in cui era implementata la parte di journal (se non ricordo male).
Inoltre il file system non si limita a definire come vengono scritti i dati su disco, ma anche come vengono gestiti in ram. Per tanto potresti ritrovarti a gestire un ext3 senza le migliorie "fisiche" dell'ext4, ma con i difetti di quest'ultimo (mi riferisco in particolare alla perdita di dati causata dalla Delayed Allocation).
Comunque fossi in te compilerei il supporto per tutt'e tre, anche perche' non sono quei 2/3k di memoria che ti appesantiscono il kernel, ma sicuramente ti risparmiano qualche problema futuro.

[Pare]

Ho provato a ricompilare il kernel senza ext2 e ext3 dentro, il risultato è un file vmlinuz più piccolo di circa 66mila byte. Non li ho compilati neppure come moduli, ma questa certamente è una sciocchezza...
Poiché sul portatile dove lo voglio mettere intendo usare solo ext4, credo che l'uso di ext2/3 sarà quasi inesistente (ho ext4 anche sul disco esterno che uso per i backup, e non sarà così frequente che mi capiti di infilare penne USB altrui formattate ext2...).
Quanto è elevato il rischio di perdere un file per colpa della Delayed Allocation? Quanto è piu' alto della possibilità di perderlo perché sfilo un disco esterno senza smontarlo e il journal, per coerenza, mi riporta allo stato di file non ancora scritto? Ovviamente, se smonto, il rischio è zero in entrambi i casi (bug permettendo), no?

[HoX]

Quanto è elevato il rischio di perdere un file per colpa della Delayed Allocation? Quanto è piu' alto della possibilità di perderlo perché sfilo un disco esterno senza smontarlo e il journal, per coerenza, mi riporta allo stato di file non ancora scritto? Ovviamente, se smonto, il rischio è zero in entrambi i casi (bug permettendo), no?

Il rischio diventa alto in caso di blackout o nel caso in cui stacchi il disco senza smontarlo. Infatti l'ext4 tiene tutti i dati in ram e li scrive una volta ogni quando gli pare (forse il sync da linea di comando forza la scrittura, ma non so). Come conseguenza ogni qualvolta il disco venga rimosso (consideriamo anche il blackout come rimozione) senza che esso sia stato smontato, la probabilita' che tu perda dati e' quasi una certezza.
Nell'ultima versione del kernel sembra comunque che il problema sia stato parzialmente risolto, ma sta di fatto che non lo sara' mai totalmente in quanto verrebbe meno la Delayed Allocation.
Se cerchi su Google comunque dovresti trovare delle guide che spieghino come rimuovere questa feature che di fatto e' utile solo su computer le cui probabilita' di blackout siano minime (vedi server attaccati ad UPS).

Fossi in te sull'hd di backup terrei un po' obsoleto, ma collaudato ext3 (perdere i dati sul disco di backup e' alquanto brutto) e comunque terrei ext2/3 almeno come moduli.

[Pare]

Ho cercato in rete Delayed Allocation ed ho trovato quasi esclusivamente documenti che ne parlano bene, dicendo che gli eventuali problemi derivano da programmi scritti male che non usano fsync() quando dovrebbero...
Nella speranza che rsync (che uso per i backup su disco esterno) sia scritto bene, penso che continuerò sulla mia strada, anche perché a fine backup smonto, quindi il rischio che un file non venga scritto non mi sembra poi tanto diverso da qualunque spegnimento improvviso durante una scrittura.
Mediterò sull'eventuale aggiunta di "nodelalloc" come opzione di mount per i dischi esterni, ma visto che non usavo "sync", non ne vedo veramente il motivo.
Quanto alle macchine stabili... il mio portatile va sempre in ibernazione senza traumi, di solito lo riavvio una volta ogni paio di mesi, raramente per ragioni diverse dal passaggio ad un nuovo kernel.

PS: e per i dati veramente importanti... uso più di un backup, su supporti distinti (possibilmente in città diverse).

[d1s4st3r]

Marco, hai pienamente ragione. La possibile perdita di dati dovuti alla delayed allocation non è dovuta al filesystem in sè quanto alla cattiva scrittura dei programmi che ne fanno uso. A titolo puramente informativo, anche il pluriaffermato XFS può soffrire di questo stesso identico problema.

So che potrei essere un pochino OT, ma ne approfitto per segnalare due guide che spiegano come migrare da ext3 ad ext4 in maniera indolore, in caso servisse a qualcuno:
http://ext4.wiki.kernel.org/index.php/Ext4_Howto#Converting_an_ext3_filesystem_to_ext4
http://telperion.wordpress.com/2009/03/01/migrare-ad-ext4/

Ciau!

[Pare]

So che potrei essere un pochino OT, ma ne approfitto per segnalare due guide che spiegano come migrare da ext3 ad ext4 in maniera indolore, in caso servisse a qualcuno.

Personalmente ho fatto in modo diverso, senza usare nessun live-CD.

1) IMPORTANTE: mi sono assicurato di avere un grub che funzionasse con ext4!!! ed un kernel con ext4 compilato dentro (un modulo nell'initrd va bene comunque, ovviamente)
2) ho messo "ext4" nell'fstab per tutte le partizioni dove volevo cambiare, inclusa la root "/"!
3) ho creato uno script /etc/rc6.d/S70changetoext4 (questo era il nome adatto sulla mia Debian, tra /etc/rc6.d/S60umountroot e /etc/rc6.d/S90reboot ) coi vari "tune2fs -O extents,uninit_bg,dir_index,has_journal /dev/DEVICEdaCAMBIARE"
4) ho riavviato... a questo punto il tutto procede in automatico: vengono smontati tutti i filesystem e la root montata in sola lettura, quindi vengono cambiati i parametri delle partizioni e si riparte; all'avvio fsck viene lanciato automaticamente, visto che i device risultano averne bisogno... m'è bastato cancellare lo script alla fine ed il passaggio era fatto.

Vi dirò di più, un riavvio è ovviamente necessario se volete cambiare il FS di root, ma fare uno script che agisca a FS smontati serve solo se dovete cambiare anche lo stato di journaling (metterlo o toglierlo), altrimenti potete lanciare tune2fs anche su partizioni montate, tanto non avrà alcun effetto fino a quando non dovrete montare nuovamente (al riavvio).

ATTENZIONE , lo dico di nuovo, ad assicurarsi che il kernel sappia leggere gli ext4 ed anche GRUB, altrimenti vi ritroverete davvero a dover riavviare con un Live-CD per rimediare ai danni (e francamente non so se sia facile tornare indietro da ext4 a ext3...). E come sempre, quando si fanno cose delicate, ma anche quando non si fanno, fate uno (o più) backup!!!