Ext3 VS Reiserfs

Postate qui per tutte le discussioni legate a Linux in generale.

Moderatore: Staff

Regole del forum
1) Citare sempre la versione di Slackware usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Gnu/Linux in genere, se l'argomento è specifico alla Slackware usate uno dei forum Slackware o Slackware64.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.

La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
enzo
Linux 0.x
Linux 0.x
Messaggi: 51
Iscritto il: mar 22 mar 2005, 0:00
Località: Reggio Calabria

Ext3 VS Reiserfs

Messaggio da enzo »

Salve a tutti!
In tutti questi anni di utilizzo delle varie distribuzioni Slackware ho sempre adoperato (da quando disponibile ovviamente) il file system Reiserfs, sia perchè pioniere del journailing, che perchè proposto come default da Patrick (e questo è per me una garanzia).
Ultimamente però, leggendo l'ultimo numero di "Linux Magazine", dove il Reiserfs viene "accusato" di abbassare drasticamente le prestazioni del sistema, mi sono sorti dubbi riguardo il suo utilizzo.
In più, non ho potuto fare a meno di notare che, nella Slackware 12.0, il filesystem proposto di default non è più Reiserfs bensì Ext3.
Allora, dovendo installare la 12.0 sul portatile ho voluto provare Ext3.
Ad essere sincero non ho notato eccessivi incrementi prestazionali rispetto a Reiserfs, ma quello che per me più conta è l'affidabilità, vengo perciò alla domanda di cui al topic:
Per vostra esperienza, come si è comportato come affidabilità Ext3 in un uso prolungato?
Riguardo Reiserfs io posso affermare di non avere mia avuto problemi con lo stesso (tocco ferro), anzi, una volta che il sistema aveva subito una serie di spegnimenti durante l'uso causa black out Reiserfs ha brillantemente recuperato tutti i dati!
Ancora, visto che si è toccato l'argomento, che file system utilizzate?
La mia configurazione più "varia" comprende, oltre al citato Reiserfs, una partizione NTFS ed una Fat32 coesistenti sullo stesso HD.
Scusate la lunghezza del topic, ho cercato nel forum se si fosse già toccato questo argomento ma non ne ho trovato memoria...

Avatar utente
aschenaz
Staff
Staff
Messaggi: 4621
Iscritto il: mer 28 lug 2004, 0:00
Nome Cognome: Nino
Slackware: current
Kernel: 5.4.x
Desktop: KDE
Località: Reggio Calabria
Contatta:

Messaggio da aschenaz »

Ciao Enzo.

Come ti dicevo, io ho cominciato con l'ext2 per poi passare all'ext3 e non ho mai avuto problemi, né con l'uno né con l'altro.

Ho trovato questo test: sembra interessante...

Avatar utente
ildiama
Linux 3.x
Linux 3.x
Messaggi: 536
Iscritto il: mar 27 dic 2005, 16:49
Slackware: mine
Kernel: 2.6.alto..
Desktop: KDE4
Località: Senigallia
Contatta:

Messaggio da ildiama »

ninobi ha scritto: Ho trovato questo test: sembra interessante...
Anche a me è sembrato interessante. Mi sa che c'è da ragionarci un pò su per cavare qualcosa da quei dati, ma almeno sono dati veri e non chiacchiere..
Per quanto riguarda il post, io uso reiserfs su 3 pc, con utilizzo molto diverso (portatile, fisso, mediacenter). Ormai sono 3 anni che non formatto nessuno dei tre e non ho mai perso un bit (o almeno non me ne sono accorto :p).
comunque una vera discriminante che ti induca a usarne uno anzichè un altro secondo me non c'è. Tolti ext2 e vfat, gli altri supportati dal kernel, coi loro pregi e difetti, sono più o meno sullo stesso piano.

Ciao.

enzo
Linux 0.x
Linux 0.x
Messaggi: 51
Iscritto il: mar 22 mar 2005, 0:00
Località: Reggio Calabria

Messaggio da enzo »

Ciao NinoBi, grazie della dritta!
Mi conforta sapere che vi siano altri (felici) utilizzatori di Reiserfs, cominciavo a pensare di essere un caso isolato...
Una domanda: sul portatile (quello con ext3) durante l'avvio appare un messaggio riguardante il "maximum count" o qualcosa del genere raggiunto da ext3 ragione per la quale dovrei lanciare un fsck.
Ricordo che un messaggio del genere mi appariva anche ai tempi di ext2, c'è da fare qualcosa?
Per ora il portatile è "sotto osservazione"....
Anche a voi (utilizzatori di ext3) appare / è apparso qualcosa del genere?

Avatar utente
syaochan
Linux 3.x
Linux 3.x
Messaggi: 659
Iscritto il: dom 9 mag 2004, 0:00
Nome Cognome: Christian
Slackware: current 64
Kernel: 2.6.38.7
Desktop: KDE 4.5.5
Contatta:

Messaggio da syaochan »

Di solito ogni n mount ext3 richiede un fsck... il numero è modificabile con tune2fs e se vuoi che il check venga fatto automaticamente basta che modifichi uno dei due numeretti in fondo alla rispettiva riga di /etc/fstab (x info precise man mount)
Ciao
クリステイアン

Avatar utente
Luci0
Staff
Staff
Messaggi: 3591
Iscritto il: lun 27 giu 2005, 0:00
Nome Cognome: Gabriele Santanché
Slackware: 12.2 14.0
Kernel: 2.6.27.46- gen 3.2.29
Desktop: KDE 3.5.10 Xfce
Località: Forte dei Marmi
Contatta:

Messaggio da Luci0 »

Si dice che reiserfs sia migliore con i file piccoli ... e qualche tempo fa lo usavo anch' io ... ho testato anche xfs che sembra il più veloce ... ma alla fine conviene usare ext3 indipendentemente dalle doti velocistiche e prestazioni ... soprattutto perché ha il tool di recupero dati migliori ...
fsck.ext3 previo utilizzo di dd_rescue mi ha permesso di recuperare un hard disk dato per illeggibile ...:-)

Simone_R
Linux 2.x
Linux 2.x
Messaggi: 218
Iscritto il: mar 12 apr 2005, 0:00
Contatta:

Messaggio da Simone_R »

Sono un sostenitore convinto di

-- XFS -- :D

Offre performance piu che buone associate ad un ottima affidabilità, ed anche un suite di applicazione di gestione del file system davvero completa.

La deframmentazione è possibile e vine eseguita in un paio di minuti al massimo.

Avatar utente
ildiama
Linux 3.x
Linux 3.x
Messaggi: 536
Iscritto il: mar 27 dic 2005, 16:49
Slackware: mine
Kernel: 2.6.alto..
Desktop: KDE4
Località: Senigallia
Contatta:

Messaggio da ildiama »

Simone_R ha scritto:Sono un sostenitore convinto di

-- XFS -- :D

Offre performance piu che buone associate ad un ottima affidabilità, ed anche un suite di applicazione di gestione del file system davvero completa.

La deframmentazione è possibile e vine eseguita in un paio di minuti al massimo.
Un file system journaled che ha bisogno di una deframmentazione :shock:
Ma sei proprio sicuro della bontà di siffatto filesystem??

Avatar utente
alessiodf
Linux 3.x
Linux 3.x
Messaggi: 823
Iscritto il: ven 14 ott 2005, 21:04
Slackware: current
Kernel: 2.6.26.4
Desktop: Kde 4.1
Località: Roma
Contatta:

Messaggio da alessiodf »

xfs here! e mi ha salvato il culetto tante di quelle volte che non ricordo piu'! :oops:

Avatar utente
gioco
Packager
Packager
Messaggi: 900
Iscritto il: dom 19 giu 2005, 0:00
Slackware: last stable
Località: in the court of the Wesnoth king
Contatta:

Messaggio da gioco »

ildiama ha scritto:Un file system journaled che ha bisogno di una deframmentazione :shock:
Perchè :shock: , un file system journaled è immune a frammentazione?

Avatar utente
ildiama
Linux 3.x
Linux 3.x
Messaggi: 536
Iscritto il: mar 27 dic 2005, 16:49
Slackware: mine
Kernel: 2.6.alto..
Desktop: KDE4
Località: Senigallia
Contatta:

Messaggio da ildiama »

gioco ha scritto:
ildiama ha scritto:Un file system journaled che ha bisogno di una deframmentazione :shock:
Perchè :shock: , un file system journaled è immune a frammentazione?
Non è che sia immune.. il problema è un pò più complesso. Io non so spiegarti bene il concetto.. ci provo a rischio di semplificare troppo.
Il file system di solito non sposta/copia fisicamente i dati, ma "si segna" le cose da fare su un file (il file di journaling) e le modifiche reali vengono fatte quando il proc ha tempo, magari ridando prima una sistematina alla sequenza di modifiche. Ne esce che la posizione dei file viene memorizzata su un "albero". Più è bilanciato questo, meno i dati sono frammentati. (E meglio lavora l'algoritmo che muove il filesystem).
Ora, se un filesystem ha un tool di deframmentazione, significa che il suo algoritmo non lavora troppo bene. Del resto si capisce che quel tool lavora sull'albero e non sui dati: non penserai che in 2 minuti deframmenta fisicamente tutti i dati di un hd !? (doppio :shock:)

Non sono stato preciso per niente.. spero di aver reso l'idea. Ciao.

Avatar utente
alessiodf
Linux 3.x
Linux 3.x
Messaggi: 823
Iscritto il: ven 14 ott 2005, 21:04
Slackware: current
Kernel: 2.6.26.4
Desktop: Kde 4.1
Località: Roma
Contatta:

Messaggio da alessiodf »

grazie della spiegazione! :D

e se si corrompe il journal? :shock: :shock: :shock: eheh li si che so dolori! tutto brodolate su lost+found senza nemmeno un nome corretto :?

Simone_R
Linux 2.x
Linux 2.x
Messaggi: 218
Iscritto il: mar 12 apr 2005, 0:00
Contatta:

Messaggio da Simone_R »

ildiama ha scritto:
gioco ha scritto:Del resto si capisce che quel tool lavora sull'albero e non sui dati: non penserai che in 2 minuti deframmenta fisicamente tutti i dati di un hd !? (doppio :shock:)
dalle istruzioni del tool:

Codice: Seleziona tutto

NOTES
       xfs_fsr  improves  the layout of extents for each file by copying the entire file
       to a temporary location and then interchanging the data extents of the target and
       temporary  files in an atomic manner.  This method requires that enough free disk
       space be available to copy any given file and that the space be  less  fragmented
       than  the  original  file.  It also requires the owner of the file to have enough
       remaining filespace quota to do the copy on systems running quotas.  xfs_fsr gen-
       erates a warning message if space is not sufficient to improve the target file.

       A temporary file used in improving a file given on the command line is created in
       the same parent directory of the target  file  and  is  prefixed  by  the  string
       '.fsr'.  The temporary files used in improving an entire XFS device are stored in
       a directory at the root of the target device and use the same naming scheme.  The
       temporary  files  are  unlinked upon creation so data will not be readable by any
       other process.

       xfs_fsr does not operate on files that are currently mapped in memory.   A  'file
       busy' error can be seen for these files if the verbose flag (-v) is set.

       Files  marked as no-defrag will be skipped. The xfs_io(8) chattr command with the
       f attribute can be used to set or clear this flag. Files and directories  created
       in a directory with the no-defrag flag will inherit the attribute.

       An  entry in /etc/mtab or the file specified using the -m option must have the rw
       option specified for read and write access.  If this option is not present,  then
       xfs_fsr  skips the filesystem described by that line.  See the fstab(5) reference
       page for more details.

       In general we do not foresee the need to run xfs_fsr on system partitions such as
       /,  /boot and /usr as in general these will not suffer from fragmentation.  There
       are also issues with defragmenting files lilo(8) uses to boot your system. It  is
       recommended  that  these  files should be flagged as no-defrag with the xfs_io(8)
       chattr command. Should these files be moved by xfs_fsr then you must  rerun  lilo
       before you reboot or you may have an unbootable system.



Il tool deframmenta i files ed è effettivamente molto veloce ed efficiente, se si fa un uso normale del disco.

È sicuramente anche aiutato da un algoritmo di allocazione dei files molto efficiente. Comunque il tempo massimo di deframmentazione previsto dal tool è di 2 ore (probabilmente applicabile con dischi molto grandi).

[Scordati i tempi biblici di Windows] :roll:

In un journaled fs le strutture dati del file system devono essere sempre coerenti, appunto con l'aiuto del journal.

Avatar utente
Luci0
Staff
Staff
Messaggi: 3591
Iscritto il: lun 27 giu 2005, 0:00
Nome Cognome: Gabriele Santanché
Slackware: 12.2 14.0
Kernel: 2.6.27.46- gen 3.2.29
Desktop: KDE 3.5.10 Xfce
Località: Forte dei Marmi
Contatta:

Messaggio da Luci0 »

Credo che la necessità di frammentazione o meno di un filesystem dipenda in larga parta dalla bontà dell sua implementazione e non dal fatto che sia journaled ...
Per fare un esempio stupido basta considerare due filesystem storici ... FAT32 e ext2fs il primo ha bisogno di essere deframmentato se si supera un certo livello di accupazione del disco, perchè le prestazioni diminuiscono ... mentre ext2 riesce ad essere performante anche se il disco é quasi del tutto pieno ...
Il journaling serve per avere quanto più possibile coerente lo stato della filesystem ... questo per ridurre al massimo i tempi di ricostruzione in caso di blocco del disco ...
Quindi per fare il check su FAT32 od ext2 ci vuole un bel pò di tempo perché ogni file deve essere controllato .. mentre se é presente una funzionalità di journaling verranno controllati solo i file che erano in scrittura al nomento del blocco ...

Avatar utente
gioco
Packager
Packager
Messaggi: 900
Iscritto il: dom 19 giu 2005, 0:00
Slackware: last stable
Località: in the court of the Wesnoth king
Contatta:

Messaggio da gioco »

Luci0 ha scritto:Credo che la necessità di frammentazione o meno di un filesystem dipenda in larga parta dalla bontà dell sua implementazione e non dal fatto che sia journaled ...
La frammentazione dipende dal metodo di allocazione dei file , in particolare dalla scelta della dimensione delle porzioni, e dalle strategie di allocazione (first fit, best fit, nearest fit).
Il journaling permette la capacità di recupero, ma non influisce sulla frammentazione fisica dei file.
Filesystem journaled necessitano di deframmentazioni (es.: JFS, NTFS).

Questo è quanto so io, sono pronto ad ascoltare se c'è altro che mi sono perso :)

Rispondi