# Gentoo su Notebook: quale filesystem? (tests inside!)

## starise

Sul mio notebook (HD hitachi 5400rpm) ho installato gentoo, con queste partizioni (+swap):

```
Filesystem        blocchi di   1K   Usati Disponib. Uso% Montato su

/dev/hda1             13678872   4093676   9585196  30% /

/dev/hda2             43936380  12266780  31669600  28% /home
```

entrambe con Reiser3. Come prestazioni non mi trovo male, solo che ultimamente eliminato completamente il dual-boot con windows mi sono accorto che la batteria si consuma piu' velocemente. Allora ho seguito l' how-to per la gestione energetica e di conseguenza ho installato i laptop-mode-tools! Ho anche utilizzato lm-profiler e ho avuto una brutta sorpresa. accessi ogni 4-5 secondi al disco da parte di reiserfs. Ora... premetto che non so se succede la stessa cosa con altri file-system (anzi, ve lo domando: succede?)

```
starbook starise # lm-profiler

Profiling run started.

Accesses at 1/600 in run: reiserfs/0

Accesses at 6/600 in run: reiserfs/0

Accesses at 11/600 in run: reiserfs/0

Accesses at 15/600 in run: reiserfs/0

Accesses at 20/600 in run: reiserfs/0

Accesses at 25/600 in run: reiserfs/0

Accesses at 30/600 in run: reiserfs/0

Accesses at 35/600 in run: reiserfs/0

Accesses at 39/600 in run: reiserfs/0

Accesses at 44/600 in run: reiserfs/0

...[CUT]
```

 L'inaspettato risultato di lm-profiler (nota: effettuato disattivando il cron e il syslog) mi ha spinto a pensare di passare ad altro filesystem, tipo ext3. Ho deciso inoltre di effettuare dei test per vedere comunque le prestazioni dei due a confronto. Naturalmente non posso passare a un filesystem troppo lento che mi compromette la velocita' dell'intero sistema.

I miei obiettivi (e di tutti quelli che usano un notebook) sono principalmente dati da questo rapporto

Prestazioni velocistiche / Accessi al disco e consumo CPU limitati

Ecco alcuni piccoli test effettuati:

Test di Velocita':

Nota: HD Acer 80GB - 4200rpm

Formattato con Ext3 (mke2fs -j - mount -o data=writeback): 69,5 GB disponibili

Formattato con Reiserfs (mkreiserfs): 74,5 GB disponibili (perche' tutta questa differenza tra ext, reiser e xfs?)

Formattato con Xfs (mkfs.xfs -b size=512 /dev/sda1 - mount -o noatime -o logbufs= :Cool: : 74,5 GB disponibili - 

(Domanda: Come mai tutta questa differenza?)

Ogni test e' stato eseguito 3 volte ed e' stato preso il risultato mediano fra i tre. Se c'era troppa differenza i test sono stati ripetuti.

Cartelle usate per il test:

/Video -> File molto grandi (>30MB) con video musicali e personali (dim. cartella: 1,6GB)

/Musica -> File medi (>3MB) con musica mp3, ogg. (dim. cartella: 702MB)

/etc -> semplicemente la cartella /etc (< 1MB) di gentoo duplicata varie volte (dim. cartella: 723MB)

---------------------------------------------------

sulla cartella /Video:

Copia

Ext3: real    2m30.768s

Reiser3: real    3m10.196s

Xfs: real    2m38.537s

Cancellazione

Ext3: real    0m2.884s

Reiser3: real    0m2.106s

Xfs: real    0m1.005s

---------------------------------------------------

sulla cartella /Musica:

Copia

Ext3: real    1m22.573s

Reiser3: real    1m14.318s

Xfs: real    1m19.715s

Cancellazione

Ext3: real    0m1.073s

Reiser3: real    0m0.279s

Xfs: real    0m0.311s

---------------------------------------------------

sulla cartella /etc:

Copia

Ext3: real    2m2.284s

Reiser3: real    1m33.039s

Xfs: real    2m30.629s

Cancellazione

Ext3: real    0m9.673s

Reiser3: real    0m3.152s

Xfs: real    0m8.974s

---------------------------------------------------

Vorrei fare altri test che mi analizzassero l'utilizzo di ram/cpu durante il processo, ma non so come fare. Comunque basandosi su questi semplicissimi dati comparativi posso dire che la fama di velocita' di reiser sui file piccoli e' giusta! Mi trovo pero' a un binario morto. Spero che qualcuno possa confermare o smentire i risultati di lm-profiler in / montato su reiserfs. Invito inoltre anche chi ha un ext3 su / a postare il risultato di lm-profiler. Capiamoci, non voglio scatenare una guerra di religione, solo effettuare un ragionamento su quale filesystem, nel 2006, e' piu' indicato per l'utilizzo su di un notebook!

----------------

NOTA: Cercando argomenti del genere sul forum ho trovato questa discussione che pero' e' del 2004. Credo proprio che da allora i kernel sono cambiati e anche le revisioni dei fs. Inoltre leggendo la discussione non ho riscontrato una cosa detta da FonderiaDigitale:

 *Quote:*   

> Reiserfs gestisce meglio i file piccoli ma si prende 30mb su una partizione (ad es. /boot) da 100 per il log del journal , quindi gia questo di per se me lo fece scartare in partenza.

  Io ho riscontrato (come potete leggere sopra) esattamente il contrario!

----------

## Cazzantonio

penso che questa discussione starebbe meglio nel forum apposito....

P.S.

formatta ext3 con 

```
mkfs.ext3 -O dir_index,filetype,sparse_super -b 1024
```

(-b 1024 è per la root o altri filesystem che contengano tanti file piccoli) e otterrai un ottimo filesystem, efficiente e sicuro...

se poi non ti basta allora sei un professionista con esigenze MOOOLTO particolari pertanto dovresti sapere te che filesystem ti serve... una discussione fatta a questo livello non aiuta nessuno e crea solo confuzione e fase certezze negli utenti

----------

## starise

Nessuna obiezione se pensi sia meglio spostarla. Non credo che si alimentino false certezze negli utenti. Non voglio mica sapere qual'è il filesustem in assoluto migliore (anche perchè ognuno direbbe una cosa diversa). Semplicemente io da utilizzatore di reiser ho notato accessi al disco troppo frequenti e siccome uso un portatile è molto importante per me limitare il consumo di risorse quando sono in viaggio. Non avendo trovato nulla riguardo a problemi di reiserfs di questo tipo e in particolare nell'output di lm-profiler, ho pensato di aprire la discussione. Poi ho deciso di arricchirla con opinioni e test sulle prestazioni dei dischi, che (almeno spero) siano gradite a qualcuno, per quanto incomplete e poco esigenti.

Comunque nessuna guerra di prestazioni. Se scopro che ext3 è meno esigente come risorse rispetto a reiser e che non accede cosi spesso al disco, sono disposto (personalmente) a cambiare filesystem anche a scapito delle prestazioni. Ogni utente naturalmente trarrà le sue conclusioni.   :Wink: 

 *Cazzantonio wrote:*   

> formatta ext3 con 
> 
> ```
> mkfs.ext3 -O dir_index,filetype,sparse_super -b 1024
> ```
> ...

  *Quote:*   

> starbook starise # cat /etc/mke2fs.conf
> 
> [defaults]
> 
>         base_features = sparse_super,filetype,resize_inode,dir_index
> ...

  *man mkfs.ext3 wrote:*   

> 
> 
>                    resize_inode
> 
>                           Reserve  space  so  the  block  group  descriptor  table  may grow in the future.  Useful for online resizing using
> ...

 In pratica mi ometti il resize_inode anche se non è che mi sia chiarissimo come funzioni. Comunque aggiungo una cosa che ho notato nel disco usato per il test:

```
starbook starise # fdisk /dev/sda1

Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel

Creazione di una nuova disklabel DOS. Le modifiche rimarranno memorizzate

solamente fino a quando si decide di scriverle. Dopodiché, ovviamente, il

contenuto precedente non potrà essere recuperato.

The number of cylinders for this disk is set to 9728.

There is nothing wrong with that, but this is larger than 1024,

and could in certain setups cause problems with:

1) software that runs at boot time (e.g., old versions of LILO)

2) booting and partitioning software from other OSs

   (e.g., DOS FDISK, OS/2 FDISK)

Attenzione: il flag 0x0000 non valido della tabella delle partizioni 4 verrà corretto con w(rite)

```

 Significa che mi converrebbe utilizzare "-b 9728" ?

----------

## Cazzantonio

 *starise wrote:*   

> In pratica mi ometti il resize_inode anche se non è che mi sia chiarissimo come funzioni. Comunque aggiungo una cosa che ho notato nel disco usato per il test:

 

```
ale@heavensdoor ~ $ cat /etc/mke2fs.conf 

[defaults]

        base_features = sparse_super,filetype,resize_inode,dir_index

        blocksize = 4096

        inode_ratio = 8192

[fs_types]

        small = {

                blocksize = 1024

                inode_ratio = 4096

        }

        floppy = {

                blocksize = 1024

        }

        news = {

                inode_ratio = 4096

        }

        largefile = {

                inode_ratio = 1048576

        }

        largefile4 = {

                inode_ratio = 4194304

        }
```

Come vedi in realtà gentoo usa di defaullt sparse_super,filetype,resize_inode,dir_index e puoi specificare il type a seconda del tipo di file ospitati sul filesystem (opzione -T di mkfs.ext3)

 *Quote:*   

>  Significa che mi converrebbe utilizzare "-b 9728" ?

 

il blocksize deve essere multiplo di 1024; a parte questo io mi limiterei a quanto descritto in /etc/mke2fs.conf

----------

## Ic3M4n

io solitamente utilizzo xfs e di solito formatto con le opzioni

```
 xfs -b size=512
```

in ogni caso trovi molte più info sull'utilizzo di xfs nel magnifico thread creato appositamente da !equilibrium.

logicamente una letta alla man page di xfs è complementare a quanto detto in quel thread.   :Wink: 

PS: aspetto l'inizio della guerra di religione.   :Laughing: 

----------

## randomaze

Moved from Forum italiano (Italian) to Forum di discussione italiano.

----------

## starise

@Cazzantonio Dal thread di equilibrium

 *Cazzantonio wrote:*   

> via mi sa che metterò xfs sulla root... backuppo e via  
> 
> Per le home aspetterò di vedere come va con la root.... per ora rimango con ext3  

  Come sono andati poi i tuoi test su xfs?

@Ic3M4n

Adesso compilo nel kernel il supporto a xfs e faccio qualche test.

P.S: Nessuno di voi che ha ext3 sulla root può fare un lm-profiler (bastano anche 30 secondi di esecuzione) per vedere gli accessi al disco?

----------

## GiRa

```
# ls /etc/runlevels/battery/

acpid  alsasound  cpufreqd  hald  laptop_mode  local  net.eth0  ntlmaps  timidity  xdm

```

Ho fatto girare a portatile inutilizzato lm-profiler per 10 minuti e non ha rilevato accessi al disco (ho provato col cavo e rilevava syslog e gli applicativi che andavano).

Quello che non capisco è questo:

```
Profiling run started.

Profiling run completed.

Program:     "anacron"

Reason:      standard recommendation (program may not be running)

Init script: none

If you want to disable this program, you should do so manually.

Program:     "cron"

Reason:      standard recommendation (program may not be running)

Init script: /etc/init.d/ntp-client (GUESSED)

Do you want to disable this service in battery mode? [y/N]:

Program:     "atd"

Reason:      standard recommendation (program may not be running)

Init script: /etc/init.d/atd (GUESSED)

Do you want to disable this service in battery mode? [y/N]:

Program:     "python"

Reason:      listens on network, may not be needed offline.

Init script: /etc/init.d/ntlmaps (GUESSED)

Do you want to disable this service in battery mode? [y/N]:

```

Che sono servizi che non erano attivi o addirittura che non ho più installati (come atd), o addirittura non ho mai installato (anacron).

----------

## .:chrome:.

dico solo una cosa: oggi, con l'imminente (relativamente) rilascio di ext4, tutti questi discorsi crollano.

ext2/3 sono i file system standard per eccellenza, quelli supportati da qualunque cosa, quelli che funzionano sempre... se a questo aggiungi che ext4...

- permette il passaggio al volo da ext2/3 a ext4 e viceversa

- in alcuni test ha dimostrato di essere più veloce di XFS

- è solido come JFS

vierne da sè quale dovrebbe essere la scelta attuale, e che gli altri file system (tutti!), se non vogliono essere spazzati via, conviene che si diano una mossa

----------

## starise

 *GiRa wrote:*   

> 
> 
> ```
> 
> Ho fatto girare a portatile inutilizzato lm-profiler per 10 minuti e non ha rilevato accessi al disco (ho provato col cavo e rilevava syslog e gli applicativi che andavano).
> ...

 

Non preoccuparti assolutamente. Anacron e ATD te le mette di default lm-profiler come scelte standard, te le mette in ogni caso, anche a me! Infatti se leggi alla riga Reason:

```
Reason:      standard recommendation (program may not be running) 
```

 Hai fatto partire lm-profiler su reiserfs?

 *.:chrome:. wrote:*   

> dico solo una cosa: oggi, con l'imminente (relativamente) rilascio di ext4, tutti questi discorsi crollano.

  Io ho sentito che è stato introdotto con il kernel 2.6.19, ma chissà quando sarà disponibile e se sarà realmente stabile. Comunque sembra promettere molto bene...

Aggiungo però, che, per quanto sia tentato dall'usare ext3, non mi va che su un disco di 80GB si succhi più di 4GB per essere formattato! Ne' reiser3 ne' xfs si mangiano tutto questo spazio!   :Mad: 

----------

## Dun

Sarei offtopic, se i moderatori me lo consigliano apro un nuovo thread, ma che filesystem consigliereste tra ext3 e xfs per un server dual p3, 1gb ram, 2x36 gb scsi con controller raid 1 hardware?

----------

## xdarma

 *starise wrote:*   

> ... Ho anche utilizzato lm-profiler e ho avuto una brutta sorpresa. accessi ogni 4-5 secondi al disco da parte di reiserfs.

 

Per caso hai abilitato le opzioni di debug e statistiche nel kernel per il ReiserFS?

```

<*> Reiserfs support

      [*]   Enable reiserfs debug mode

      [*]   Stats in /proc/fs/reiserfs

      [ ]   ReiserFS extended attributes

```

----------

## Kernel78

Io non ho votato per il test visto che ho provato soltanto tre di quei fs e solo uno di questi su un portatile.

Sarei curioso di capire se chi ha votato l'ha fatto con cognizione di causa e in base a dati oggettivi o in base a sensazioni soggettive...

Che test avete fatto per valutare l'efficienza e quali parametri avete ritenuto più pesanti sul giudizio ?

Vorrei capire se (dati assolutamente casuali) rilevando che su una partizione da 100gb il fs 1 dia 98 gb liberi mentre il fs 2 ne dia liberi solo 93 ma quest'ultimo risulti fare 1/3 degli accessi al disco in meno rispetto al primo ma sfrutti più cpu per ogni accesso (anche se non saprei come valutare lo sfruttamento della cpu da parte di un fs) quale giudizio comporterebbe ? Sarebbe meglio il primo o il secondo ?

Sono anche io del parere che una discussione del genere possa soltanto generare confusione, l'unica possibilità sarebbe trovare il modo di effettuare dei benchmark su ogni aspetto di ogni fs e postare i risultati, sarebbe poi ogni singolo utente a valutare quale parametro ritiene più importante.

Il solito tentativo di dire "per me è meglio questo" o "per me è meglio l'altro" è inutile in quanto le preferenze espresse si basano su una moltitudine di fattori soggettivi.

A questo punto avrebbe la stessa valenza discutere se uno preferisce doppia porzione di dolce o doppia porzione di spezzatino ... oppure ci mettiamo a discutere se è meglio il mare o la montagna ... non si arriva da nessuna parte.

----------

## Cazzantonio

 *starise wrote:*   

>  Come sono andati poi i tuoi test su xfs?

 

Non voglio con questo offendere nessuno ma IMHO non ne vale la pena... io personalmente non sono in grado di percepire alcuna differenza con ext3 formattato bene. Ad oggi comunque ext3 è il filesystem più sicuro in assoluto quindi...

----------

## Kernel78

Ho trovato un test abbastanza serio qui.

Con dati oggettivi è più semplice prendere una decisione.

----------

## Ic3M4n

dati oggettivi è vero... però la stessa cosa sarebbe da prendere in considerazione con i vari parametri per la formattazione e per il mount del device.

dopotutto:

```
NAME

       mke2fs - create an ext2/ext3 filesystem

SYNOPSIS

       mke2fs [ -c | -l filename ] [ -b block-size ] [ -f fragment-size ] [ -g

       blocks-per-group ] [ -i bytes-per-inode ] [ -j ] [ -J journal-options ]

       [  -N  number-of-inodes ] [ -n ] [ -m reserved-blocks-percentage ] [ -o

       creator-os ] [ -O feature[,...]  ] [ -q ] [ -r fs-revision-level ] [ -E

       extended-options ] [ -v ] [ -F ] [ -L volume-label ] [ -M last-mounted-

       directory ] [ -S ] [ -T filesystem-type ] [ -V ] device [  blocks-count

       ]

```

```
NAME

       mkfs.xfs - construct an XFS filesystem

SYNOPSIS

       mkfs.xfs [ -b subopt=value ] [ -d subopt[=value] ]

            [ -i subopt=value ] [ -l subopt[=value] ] [ -f ]

            [ -n subopt[=value] ] [ -p protofile ] [ -q ]

            [ -r subopt[=value] ] [ -s subopt[=value] ]

            [ -N ] [ -L label ] device

```

le varie opzioni che uno può abilitare/disabilitare o utilizzare dei valori differenti rispetto a quelli di default possono variare sensibilmente (nei benchmark, dubito fortemente che si possano avvertire ad occhio durante l'utilizzo giornaliero) le prestazioni del filesystem. inoltre secondo me nel test che hai linkato non viene preso in considerazione l'aspetto della robustezza di un filesystem, ovvero quanto è facile/impossiblie recuperare dei file a seguito di crash o corruzioni. se trovo qualche info anche su questo tipo di problematica magari la posto.

----------

## xdarma

 *Cazzantonio wrote:*   

> ... Ad oggi comunque ext3 è il filesystem più sicuro in assoluto quindi...

 

La mia esperienza personale mi porta a dire che ext3 è il filesystem che di sicuro ti fa perdere dati. Forse è meno buggato di altri ma tutte le pagine web che ho trovato sul data recovery di ext3+kernel2.6 portano alla stessa conclusione: non recupererai nemmeno un byte. Per altri filesystem (tipo ReiserFS) forse ti salvi in extremis. Spero di non scatenare flame ma ti giuro che sto pagando cara la scelta di un filesystem "sicuro, compatibile, stabile" e non appena possibile cambierò ext3 con qualcos'altro.

----------

## Kernel78

 *xdarma wrote:*   

>  *Cazzantonio wrote:*   ... Ad oggi comunque ext3 è il filesystem più sicuro in assoluto quindi... 
> 
> La mia esperienza personale mi porta a dire che ext3 è il filesystem che di sicuro ti fa perdere dati. Forse è meno buggato di altri ma tutte le pagine web che ho trovato sul data recovery di ext3+kernel2.6 portano alla stessa conclusione: non recupererai nemmeno un byte. Per altri filesystem (tipo ReiserFS) forse ti salvi in extremis. Spero di non scatenare flame ma ti giuro che sto pagando cara la scelta di un filesystem "sicuro, compatibile, stabile" e non appena possibile cambierò ext3 con qualcos'altro.

 

Con data recovery intendi recuperare file cancellati o recuperare dati dopo un crash o altro ancora ?

----------

## GiRa

Appunto, non si può pretendere come feature "voglio che se cancello dei dati io li possa recuperare" contemporaneamente a quelle che fornisce ext3.

Tornando molto IT: no, non ho provato con Reiser dato che non ho nessuna partizione con ReiserFS. Uso ext3 formattato di default anche se è da un pezzo che sto pensando di tenere degli inode più piccoli per la / in modo da sfruttare meglio lo spazio. Solo che, si sa, finchè una cosa va bene non è che ti venga molta voglia di andarci dietro  :Very Happy: 

----------

## .:chrome:.

 *xdarma wrote:*   

> La mia esperienza personale mi porta a dire che ext3 è il filesystem che di sicuro ti fa perdere dati

 

peccato che in realtà le cose siano l'esatto contrario.

come hanno detto gli altri, cosa vuol dire "recuperare dati"? comunque tu lo intenda, quelle non sono le normali condizioni di funzionamento del file system.

in condizioni normali ext2/3 sono i file system più sicuri e che espongono a meno rischi in assoluto. cosa ben diversa dall'altro che hai citato

----------

## xdarma

 *starise wrote:*   

> I miei obiettivi (e di tutti quelli che usano un notebook) sono principalmente dati da questo rapporto
> 
> Prestazioni velocistiche / Accessi al disco e consumo CPU limitati

 

In questo thread what is eating my battery? sembra abbia dato risultati positivi una diversa impostazione dello swappiness.

Ma dovresti contattare l'utente per conferma.

----------

## devilheart

salve a tutti.

per natale mi sono regalato un bel disco fisso nuovo per il portatile, e per l'occasione ho deciso di rivedere lo schema delle partizioni. in particolare farÃ² partizioni separate per

/boot

/home

/

/usr

ora per /boot userÃ² ext2 che di piÃ¹ non serve. per /home pensavo di usare ext4 dato che gli unici dati sensibili/importanti di tutto il sistema staranno li dentro. per / e /usr invece sono indeciso. considerando che in / ci staranno files di piccole dimensioni, mentre in /usr ci staranno files di qualsiasi dimensione, che filesystem potrei usare?

considerate anche che per / e /usr voglio l'fs che da le migliori prestazioni in lettura e scrittura. l'affidabilitÃ  Ã¨ completamente trascurabile in questo caso

----------

## Ic3M4n

perchè bisogna dare inizio al classico flame? è come dire se è meglio gnome o kde, grub e lilo.

c'è un thread di poco tempo fa che ne parla. appena lo trovo lo posto.

----------

## Luca89

Io userei in tutti xfs tranne per boot dove metterei ext2. Inoltre ext4 non lo vedrei molto affidabile visto che è ancora in prematuro stato di sviluppo.

P.S: quoto Iceman, qualche topic simile dovrebbe già esserci, quindi ci si potrebbe accodare lì.

----------

## crisandbea

 *devilheart wrote:*   

> salve a tutti.
> 
> per natale mi sono regalato un bel disco fisso nuovo per il portatile, e per l'occasione ho deciso di rivedere lo schema delle partizioni. in particolare farÃ² partizioni separate per
> 
> /boot
> ...

 

ciao io uso in tutte la partizione xfs, ed per ora mai avuti problemi. ti linko un sondaggio di poco tempo fa ciao

https://forums.gentoo.org/viewtopic-t-522275.html

ciauz

----------

## Ic3M4n

ecco che qualcuno si è sbattuto più di me per trovarla   :Wink: 

----------

## cloc3

 *devilheart wrote:*   

> usare ext4 

 

 :Shocked:   :Shocked:   :Shocked: 

stragulp. che è, si mangia???

 :Shocked:   :Shocked:   :Shocked: 

Ah, no.

Lo hanno inventato su wikipedia, ma non esiste lo stesso.

 :Laughing: 

----------

## randomaze

 *Ic3M4n wrote:*   

> ecco che qualcuno si è sbattuto più di me per trovarla  

 

Ringrazio anche io  :Wink: 

Merge effettuato.

----------

## devilheart

 *cloc3 wrote:*   

>  *devilheart wrote:*   usare ext4  
> 
>   
> 
> stragulp. che ï¿½, si mangia???
> ...

 veramente Ã¨ giÃ  presente nel kernel, in versione experimental

----------

## Ic3M4n

si, esatto in versione experimental. io non ci metterei su i miei dati importanti. un po' come utilizzare reiser4. fino a che non è stabile e testato si scordano che io li utilizzi per mettere su i miei dati.

----------

## cloc3

 *devilheart wrote:*   

> veramente è già  presente nel kernel, in versione experimental

 

non te la prendere.

stavo palesemente scherzando sulla sorpesa di scoprire un coso nuovissimo di cui ignoravo l'esistenza.

altrimenti non avrei citato wikipedia. se sta lì, è ovvio che ci sia anche nel kernel.

grazie per l'informazione.

----------

## Frez

Io utilizzo ext3 per / (contiene anche la preziosa /home) e JFS per /usr. Ho spostato linkato /opt -> /usr/opt visto che anche quelli non sono file essenziali.

Con questa configurazione posso bootare e fare un fsck.jfs senza dover ricorrere ad un cd di boot.

Piccoli tweak per ext3:

```
mkjf.ext3 -J size=256 -O dir_index,filetype,has_journal /dev/hdX
```

e

```
tune2fs -o journal_data /dev/hdX
```

L'opzione journal_data dovrebbe essere piu' lenta rispetto a journal_data_writeback, ma nella pratica sembra essere il piu' veloce in caso di accesso sia scrittura che lettura (vedi Articolo di Robbins)

Soprattutto rimane una opzione "safe", il che ha la precedenza sulla estremizzazione delle prestazioni.

Per l'albero del portage sto utilizzando squashfs+unionfs e sembra estremamente veloce. Anzi, non "sembra", e' veloce visto che ho un misero 4200rpm e bastano 10 secondi per aggiornare la cache del portage.

Per JFS ho incrementato le dimensioni del journal e basta (non credo si possa fare altro  :Smile:  )

/var/tmp/portage e' rigorosamente in RAM (2 GB, poi dicono che sono "smemorato"  :Smile:  )

----------

## IlGab

 *starise wrote:*   

> 
> 
> Formattato con Ext3 (mke2fs -j - mount -o data=writeback): 69,5 GB disponibili
> 
> Formattato con Reiserfs (mkreiserfs): 74,5 GB disponibili (perche' tutta questa differenza tra ext, reiser e xfs?)
> ...

 

Ext3 riserva un 5% di spazio sul disco per root in nel caso in cui il disco si riempia e i processi non riescano più a partire. Con questo spazio root può effettuare le operazioni di pulizia e far ripartire la macchina.

----------

## Peach

 *Frez wrote:*   

> 
> 
> ```
> tune2fs -o journal_data /dev/hdX
> ```
> ...

 

si ma nell'articolo si parla di opzioni di mount, non di opzioni di formattazione del file system (o di post tuning).

non solo... l'articolo è del 1° dicembre 2001...  :Embarassed: 

----------

## Dun

 *Frez wrote:*   

> Io utilizzo ext3 per / (contiene anche la preziosa /home) e JFS per /usr. Ho spostato linkato /opt -> /usr/opt visto che anche quelli non sono file essenziali.
> 
> Con questa configurazione posso bootare e fare un fsck.jfs senza dover ricorrere ad un cd di boot.
> 
> Piccoli tweak per ext3:
> ...

 

Segnalo una cosa che mi ha provocato non pochi grattacapi:

Utilizzando ext3 con il journal in modalita' journal_data invece che ordered mode si incontrano un paio di problemi nel caso si utilizzi un kernel XEN e il domU abbia come "/" un file formattato in ext3. 

Anche montandolo con l'opzione tap:aio di xen uno shutdow  brusco del domO porta alla corruzione di tutti i domU. 

Riportando il fs del domO a ext3 in ordered mode si evita la corruzione anche a seguito di fsck di verifica.

Cya!

----------

## xdarma

 *starise wrote:*   

> Ho anche utilizzato lm-profiler e ho avuto una brutta sorpresa. accessi ogni 4-5 secondi al disco da parte di reiserfs. Ora... premetto che non so se succede la stessa cosa con altri file-system (anzi, ve lo domando: succede?)
> 
> ```
> starbook starise # lm-profiler
> 
> ...

 

Resuscito il thread perchè, casualmente, credo di aver trovato conferma "autorevole" ai miei (inattendibili) test: anche su ext3 lm-profler registra accessi ogni 5 secondi circa. La causa sembra sia il kernel, non il filesystem:

 *Quote:*   

> 
> 
> Laptop Mode:
> 
> JA: Shortly after posting your original CFQ scheduler patch, you posted a patch introducing the "laptop_mode" sysctl that has also since been merged into the mainline Linux kernel. How does laptop mode improve battery life on laptops?
> ...

 

Quindi sembrerebbe che il consumo energetico del disco fisso sia fortemente dipendente dal comportamento del kernel.

Apparentemente nella scelta del filesystem più adatto ad un portatile, il consumo energetico sembra non essere un parametro di cui tener conto.

Strano che nessuno degli ext3-fan e XFS-fan abbia condotto delle prove in privato e le abbia pubblicate  ;-)

----------

## bandreabis

up.

Interessante questa discussione... peccato si sia fermata.

----------

## GiRa

 *xdarma wrote:*   

> Strano che nessuno degli ext3-fan e XFS-fan abbia condotto delle prove in privato e le abbia pubblicate  

 

Il mio lm-profiler era girato per 10 minuti senza nessun accesso al disco con laptop_mode abilitato... Dato che si parlava di funzionamento a batteria mi pareva scontato.

----------

