File system performante

Ciao,

io ho una partizione su cui manipolo le versioni del mio root file
system (a scopo didattico)

Mi trovo quindi su questa partizione diverse versioni da diversi giga.

Manipolo usando per esempio il comando rsync, tar, ecc ...

Ext3 non mi da particolari soddisfazioni, voi avete qualche file
system che consigliereste
per questo tipo di attivita' con performance maggiori?

Dipende da cosa fai...

# reiserfs se ci sono molti file piccoli
# ext4 è in genere meglio di ext3 (sia come performance che come
  sicurezza...prova a cancellare un disco o a fare un check del fs per
  esempio...) per via degli extend

# xfs è stato il fs più performante su linux per molto tempo e ancora
  adesso non è male (e i suoi strumenti di gestione sono ottimi...)

# btfs dovrebbe succedere a ext4 e dovrebbe andare ancora più veloce
  (ma non è da usare in produzione a causa del fatto che il suo formato
  non è ancora stabile...)

IMHO prova ext4...

bye

Ciao,

io ho una partizione su cui manipolo le versioni del mio root file
system (a scopo didattico)

Mi trovo quindi su questa partizione diverse versioni da diversi giga.

Manipolo usando per esempio il comando rsync, tar, ecc ...

Ext3 non mi da particolari soddisfazioni, voi avete qualche file
system che consigliereste
per questo tipo di attivita' con performance maggiori?

"non da` particolare soddisfazioni" non e` una buona metrica
per valutare la performance di un file system...

Mentre esegue una delle tue operazioni tipiche, qual'e` l'output
di "vmstat 1" durante mezzo minuto?

E mentre il sistema fa niente, qual'e` l'output di
hdparm -t -T /dev/XXX dove XXX e` il tuo disco?

Stai copiando/tarando/rsyncando da una partizione all'altra dello
stesso disco? Se si`, questo e` comunque inefficiente, vedresti
uno speed-up enorme se riusciresti a usare due dischi piuttosto,
indipendentemente dal file system.

Bye,
Chris.

Ciao,

grazie dei suggerimenti, vi riporto la mia esperienza:

A) ho provato a cambiare da ext3 a ext4, xfs e reiserfs. Devo dire che
in tutti i casi ho visto un miglioramento
     e, per le mie limitate prove, ext4, xfs, reiserfs sembrano girare
tutti piu' o meno similmente a circa il doppio di ext3

B) hdparm mi da un valore massimo di circa 70M/s che e' il tempo che
spesso vedo durante le operazioni,
    quindi questo probabilmente la velocita' massima che riesco ad ottenere...

C) Chris anch'io credo sia meglio usare 2 dischi proprio diversi cosi'
la meccanica non continua a spostarsi,
     ma nel portatile ne ho solo uno :wink: Dici che un disco usb
potrebbe migliorare comunque? Provo ...

E gia' che siamo in argomento, visto che anche i progetti java con cui
lavoro sono piuttosto grandi ... e anche li
noto che il disco "frulla" in continuazione ...

C'e' una qualche soluzione per avere dischi super performanti che mi
potreste consigliare? Non so,
avere un disco allo stato solido, magari esterno, aumentare la cache
in memoria ... ecc? Se fosse esterno
magari non usb ma ...

Buona domenica :slight_smile:

Scusate ho due integrazioni:

B) la velocita' e massima e' di 70MB/s ... che magari senza la B
sembrava 8 volte di piu' :wink:

Seconda cosa riguardo alle performance, un altra idea che mi viene in
mente e se usare
un RAID, non tanto per l'affidabilita', ma so che in alcune
configurazioni le letture
possono avvenire parallele su + dischi .. (o forse anche le scritture ... )

Scusate ho due integrazioni: B) la velocita' e massima e'

    > di 70MB/s ... che magari senza la B sembrava 8 volte di
    > piu' :wink:

    Senza la B ... poteva sembrare otto volte di meno, direi. Le due
    possibilità "ovvie" sono bit (Mb) o byte (MB), e 70Mb/s sono meno
    di 70MB/s.

    > Seconda cosa riguardo alle performance, un altra idea che
    > mi viene in mente e se usare un RAID, non tanto per
    > l'affidabilita', ma so che in alcune configurazioni le
    > letture possono avvenire parallele su + dischi .. (o forse
    > anche le scritture ... )

    Sul fatto che una serie di dischi in RAID "vada più veloce" di un
    povero disco "solitario" (dello stesso tipo, ma anche
    relativamente più veloce) sarei disposto a scommettere anche una
    pizza. Ma prima parlavi di un portatile ... quindi un solo
    disco).

    In realtà già passare da un disco a più dischi fa un bella
    differenza, soprattutto se riesci a distribuire il carico.
    Esempio scemo: se il tuo lavoro Java (no comment!) provoca molti
    accessi alla tua directory di lavoro (/home/...) ma anche a
    strumenti e librerie (/usr/... immagino) avere le due cose su due
    dischi separati aiuterebbe. Oppure, se vengono generati molti
    file temporanei aiuterebbe avere /tmp da qualche altra parte.

    Forse anche avendo un disco solo, avere partizioni separate
    potrebbe aiutare (io lo faccio per abitudine, /tmp separata, e
    anche per tenere ordine, /home separata) ma su questo non più di
    un caffé.

       buone prove, Luca

PS: Riguardo i saggi consigli di Chris, ancora una volta penso al
    fatto che per eseguire molti comandi "di lettura" (in hdparm, -t e
    -T fanno solo statistiche e non "modificano nulla") si debbano
    invocare &da root* gli stessi comandi che, sbagliando una opzione,
    di fiondano il disco.

    Un minimo di "separazione di tipo di attività", magari con due
    livelli di "rootness" (o equivalenti via sudo) non ci starebbe
    male. Vabbé, era giusto per avere la solita perte di critiche :slight_smile:

Davide wrote:

E gia' che siamo in argomento, visto che anche i progetti java con cui
lavoro sono piuttosto grandi ... e anche li
noto che il disco "frulla" in continuazione ...

Sei sicuro che un disco piu' performante e' la soluzione al tuo problema e non
un paio di GB di RAM in piu'?

Magari ti conviene collezionare un po' di dati con sysstat (o altro) durante
un giorno di lavoro tipico.

Th

Con Java...è possibile, magari se abbiamo una descrizione un po' più
accurata del sistema si può essere un po' più utili...

In particolare:

- SO
- CPU
- Freq. CPU
- HD
- tipo di sistema (portatile/fisso)
- applicazione
- ram usata dall'applicazione (top)

ecc.