slacky.eu

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...

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...

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

).
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.

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?

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
ｸﾘｽﾃｲｱﾝ

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 ...

Sono un sostenitore convinto di

-- XFS --

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.

Simone_R ha scritto:Sono un sostenitore convinto di

-- XFS --

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

Ma sei proprio sicuro della bontà di siffatto filesystem??

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

ildiama ha scritto:Un file system journaled che ha bisogno di una deframmentazione

Perchè

, un file system journaled è immune a frammentazione?

gioco ha scritto:
ildiama ha scritto:Un file system journaled che ha bisogno di una deframmentazione
Perchè , 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

)

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

grazie della spiegazione!

e se si corrompe il journal?

eheh li si che so dolori! tutto brodolate su lost+found senza nemmeno un nome corretto

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 )

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]

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

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 ...

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

slacky.eu

Ext3 VS Reiserfs

Ext3 VS Reiserfs