Newsgroup: it.comp.os.linux.sys
Titolo: Ext3, copia file leeeenta

Se mi metto a scrivere, via dd, 1GB sulla SAN ci metto circa 9 secondi,
a blocchi di 1024 byte. Se copio 4,5 GB di file veri e propri, passo
non a 9*4,5 secondi=40 secondi, ma a 16 minuti.
Ho sentito di questi metadati :), pero' e' un rallentamento di 24
volte. Peraltro e' un problema storico, mi ricordo che l'ho incontrato 
una volta ai tempi di RHEL 2.1.
Cambiare file system non si puo', e' una RHEL 4.x kernel aggiornato
all'ultimo disponibile, altre idee? Magiche configurazioni di elevator,
scheduler e dintorni?
-- 
Per rispondermi, sostituisci a nomecognome il mio nome e cognome
To reply me, substitute nomecognome with my real name and surname
http://bitsandchaos.wordpress.com

 
Utilizzi dd per scrivere direttamente sulla partizione? o in un file?
Nel primo caso il filesystem non c'entra assolutamente nulla.
Nel secondo, invece, si può provare a vedere.
Ad ogni modo, per quello che ho visto io, dd non è proprio una scheggia
nella lettura/scrittura su disco. Per velocizzare un po', prova a
cambiare la dimensione dei blocchi di lettura/scrittura (parametro BS)
Con i miei sistemi utilizzo un valore di 8Mbyte a blocco. In questo modo
riesco a sfruttare meglio le cache dei dispositivi e del filesystem.
Se mi chiedi perché 8M, ti rispondo che è un valore empirico. Ho notato
che con questo valore si ha un aumento di prestazioni significativo
rispetto al block size di default e non avevo molto tempo per provare
altri valori. Considera che i dischi hanno a bordo cache di qualche MB.
PSK

 volta ai tempi di RHEL 2.1.
Provato ad aumentare le dimensioni del journal e il tempo di commit?
Il journal come e` configurato (ordered, journal o writeback)?
Bye.

 moduli oltre ext3?
Su RHEL 5 c'è GFS e OCFS, di serie. Su RHEL 3-4 GFS è a pagamento. 


 cambiare la dimensione dei blocchi di lettura/scrittura (parametro BS)
Ma hai capito di cosa stiamo parlando?


 Fra l'altro ho come il dubbio che ocfs sara reso obsoleto da btrfs.
Non mi pare che btrfs sarà un cluster file system, o sbaglio?
Y.

 Ho sentito di questi metadati :), pero' e' un rallentamento di 24
Ext3 e` pessimo in scrittura a meno che non si monti con 
nobh,data=writeback e relativo tune2fs -o journal_data_writeback /dev/..
-- 
Vincenzo

 moduli oltre ext3?
No. La politica di Red Hat (se non sbaglio dalla 9 in poi) e` di
supportare ext3. Di conseguenza, tutti gli altri file system supportati
dal kernel, non venivano nemmeno compilati come moduli (ti lascio
immagineare come mi risentii quando provai le prime Fedora, e /home era
formattata in XFS). Solo attualmente Red Hat si e` aperta alla
sperimentazione di altri file system oltre a ext3. Difatti, dopo che per
qualche tempo circolava una versione di Fedora ricompilata per il
supporto a XFS, ora tale file system e` supportato ufficialmente (non
saprei dire pero` sulla versione commerciale)
Enrico

 Scusa la franchezza, ma che schifezza... cioe' hai un solo FS con RHEL?
Tanto schifezza non lo vedo. La scelta di Red Hat, all'epoca, fu quella
di supportare bene un file system, tralasciando gli altri (sia per un
discorso organizzativo, sia per un discorso economico). Se poi consideri
che Red Hat e` il principale sponsor di ext3 (tanto che parte degil
sviluppatori sono pagati direttamente dall'azienda dal cappello rosso),
allora direi che hanno fatto bene le loro scelte
Enrico

 Scusa la franchezza, ma che schifezza... cioe' hai un solo FS con RHEL?
No, ma non hai fs che si sovrappongono in quanto ad ambito di utilizzo
ottimale.


 Vuol dire che un filesystem che non puo' contenere piu' di 32mila file
Adamo, sinceramente non ho capito se ti diverti a fare il troll oppure
se proprio non ci arrivi:
ebianchi@bart:/tmp/a$ df -hTP|grep /tmp
/dev/mapper/vg01-tmp ext3  2.0G   70M  1.9G   4% /tmp
ebianchi@bart:/tmp/a$ for i in `seq 1 45000`; do touch $i; done
ebianchi@bart:/tmp/a$ ls -1|wc -l
45000
ebianchi@bart:/tmp/a$ rm *
ebianchi@bart:/tmp/a$ for i in `seq 1 33000`; do mkdir $i; done
mkdir: cannot create directory `31999': Too many links
mkdir: cannot create directory `32000': Too many links
[...]
ebianchi@bart:/tmp/a$ ls -1|wc -l
31998
ebianchi@bart:/tmp/a$
Basta questo per farti entrare in quella testaccia che il limite di
32000 elementi e` riferito alle DIRECTORY e non ai FILE?
Enrico

 scrivo. So bene che il limite si riferisce alle directory.
quindi tu pensi veramente che sia un grosso problema non poter creare più di
32000 subdirectory per directory in una Maildir o su un proxy server?

 sufficiente un "modprobe <fs>", non vedo perche' non farlo.
Il costo di amministrazione.


 performante e' reiser.
"Sicuramente" significa "non puo' che essere cosi', ti pare che con tutta la
fatica che hanno fatto a scriverlo sia piu' lento", e mi spiace ma io al
"sicuramente" non credo, sicuramente. 


 xfs....
Tende a non perdere i dati.


 
http://linuxgazette.net/102/piszcz.html
Con un kernel 2.4? Bella forza.


 
http://linuxgazette.net/102/piszcz.html
Questo e` vecchissimo (2004), ma ce n'e` uno ancora piu` vecchio (2002) in 
cui ext3 e` comunque piu` performante di reiser:
http://www.gurulabs.com/goodies/ext3_vs_reiserfs-1.php
In pratica, si rincorrono da piu` di 6 anni.
Solo che adesso ext3 viene sviluppato attivamente, e reiser3 fa solo 
mantenimento, mentre reiser4 non vede la luce in fondo al tunnel.
ext3 e` sempre stato il piu` bilanciato. Buone prestazioni, ottima 
affidabilita`, perfetta compatibilita`, buona "tunabilita`".
Bye.

 porrei questi problemi per nulla: sono morti entrambi.
Il problema e` che i server li ho in produzione adesso, e devo metterci 
qualcosa, non posso aspettare che sviluppino un fs per metterli in 
produzione. :)
Per ora ext3 e` il miglior compromesso, e non mi ha mai tradito in 12 anni 
(contanto anche ext2), a differenza di reiser che mi ha gia` costretto al 
restore 3-4 volte.
XFS e JFS non li ho mai usati semplicemente perche` non li usa 
(relativamente) nessuno, su Linux. Preferisco una cosa testata. E` un 
filesystem, non un player di video che se si pianta ricomincio a vedere il 
filmato. Non deve avere bug, non deve piantarsi, non deve corrompere i 
dati. Se fa queste cose, le prestazioni diventano secondarie.
Fortunatamente lavoro in ambiente web, e nel 99% dei casi il collo di 
bottiglia e` la rete, non il fs.
Bye.

 sufficiente un "modprobe <fs>", non vedo perche' non farlo.
al solito svicoli.
ricompilati il kernel, lo puoi fare anche su red hat.
rinunci al supporto.
scelta loro, scelta tua.

 (relativamente) nessuno, su Linux
Per JFS ti do ragione, per XFS basta prendere un amministratore
qualsiasi che abbia un minimo di conoscenze e che usa Debian
Enrico

 C'e' dietro l'angolo btrfs
Guarda che brtfs potrebbe rivelarsi peggiore di quanto credi. Ad un file
system prima vengono richieste determinate prestazioni, poi le
funzionalita` (e` anche per questo motivo che sconsiglio sempre e
comunque l'uso di NTFS-3G)
Enrico

 mi si puo' dire il contrario.
non scegli red hat per avere la più ampia scelta possibile.
non solo come filesystem, anche come software distribuito.
tu la vedi come una scelta riduttiva, rh la vede come una scelta di
stabilità ed efficienza.
dal loro punto di vista tu hai torto, e non si può dire loro il contrario.

 
perché mai decidere di concentrare il supporto su un filesystem di cui tra
l'altro si è mantainer significherebbe dar torto al resto del mondo?
Novell supporta reiserfs e xfs in aggiunta, ma non jfs nè altri fs.
e inoltre:
"For SUSE Linux Enterprise 11, Novell will be changing the default file
system in new installations from ReiserFS 3 to ext3."
Canonical non so bene che cosa supporti.

gt wrote:

Si parla solo di _default_, scelta già adottata nella opensuse 10.3. 
Che oggi ext3 venga proposto come default è abbastanza ovvio.
IMHO, alla RH hanno le braccine corte :)
Ciao.
-- 
*** Linux user # 198661 ---_ ICQ 33500725 ***
    ***  Home  
http://www.kailed.net
  ***
        ***  Powered by openSUSE  ***

 IMHO, alla RH hanno le braccine corte :)
ogni distribuzione che punti ad offrire un sistema estremamente stabile ha
le braccine corte in qualche modo.

 JFS e' strano e ha zero tool.
La mancanza di strumenti non significa che non ha funzionalita`,
semplicemente le implementa in maniera differente o le integra negli
strumenti gia` esistenti. Un esempio di tale approccio e` proprio il
ridimensionamento, che e` implementato a livello di opzione di mount, e
non a livello di applicazione. Personalmente ritengo che JFS avrebbe
meritato piu` visibilita`, purtroppo pero` sappiamo tutti come sono
andate le cose (emblematico probabilmente il fatto che nelle prime
versioni del kernel in cui era incluso, vi era un bug che causava la
corruzione del file system stesso). Sarebbe interessante se qualcuno ne
riprendesse lo sviluppo (dato che IBM oramai fa solo manutenzione),
anche perche` le sue caratteristiche lo rendono interessante in tutti
quegli ambiti in cui e` importante tenere sotto controllo le prestazioni
(sistemi embedded, macchine virtuali...)
Enrico

 stabile ha le braccine corte in qualche modo.
Si ma non è che con un FS sei stabile e con due no..
Ovviamente devi avere in casa qualcuno capace di metterci mano. Proprio
il motivo che ha spinto Novell ad eliminare il supporto a JFS (parliamo
dell'installazione, il supporto nel kernel è presente..).
I due casi però non sono paragonabili, Jfs non se lo è mai filato
nessuno, reiser ha avuto il suo momento di gloria con una buonissima
diffusione..
Poi i motivi potrebbero anche essere altri, reiser in passato
sponsorizzato da Suse, l'ext3 fatto in massima parte da loro... brutta
bestia il marketing..
Tra tutte le possibili motivazioni, quella più strettamente tecnica, mi
sembra la meno plausibile..


 migliore.
Direi che e` normale, visto l'ostruzionismo per Reiser4 e la
terminazione dello sviluppo di Reiser3. Tra l'altro, non capisco come
mai Novell (o SuSE) non abbia acquisito Namesys, portandola quindi ad un
livello piu` vicino a Red Hat
Enrico

 Loro per le soluzioni high-end propongono GFS.
GFS non c'entra niente con ext3 e compagnia cantante. GFS e`
un file system di rete
Enrico

 perché mai?
Beh, un riassunto della situazione lo feci qualche tempo fa': ext (in
tutte le sue incarnazioni) e` l'unico file system attivamente
sviluppato, tutti gli altri o sono in uno stato embrionale (e.g. brtfs),
o si trovano in uno stato vegetativo di manutenzione (e.g. ReiserFS,
JFS, XFS)
Enrico

 xfs....
Perche` attualmente ReiserFS e XFS sono piu` morti che vivi. Per XFS
c'e` comunque da dire che sembra che stiano puntando piu` nell'affinare
gli strumenti di gestione che nell'aggiungere nuove funzionalita` al
file system (che e` comunque una buona cosa)
Enrico
P.S. personalmente uso ext3 perche`, come ho detto, e` quello piu`
attivo, non perche` me lo suggerisce RH e compagnia cantante

 Cerca di rivedere un po' le tue idee ... 
Sicuramente le rivedro`, ma solo quando avro` qualcosa di veramente
usabile in mano (cosa che ora non c'e`)
Enrico



Non intendo "trovare gente che configurarlo", ma proprio "quanta gente lo 
usa, ci trova bug, li segnala e li corregge".
Da questo punto di vista ext3 ha un parco utenti molto piu` ampio di xfs, 
quindi ha piu` probabilita` che vengano trovati i bug, che vengano 
sviluppati miglioramenti e, perche` no, che qualcuno mi risponda su un 
newsgroup se ho un problema col fs. :)
Bye.

 Ciao.
quando è uscita la notizia che Novell voleva passare ad ext3 di default, più
di un anno e mezzo fa, le ragioni addotte erano sia tecniche (scalabilità,
scarse prestazioni con gli extended attributes) che di prospettiva.
http://lists.opensuse.org/opensuse-factory/2006-09/msg00542.html

 livello piu` vicino a Red Hat
infatti. a livello di marketing avrebbe sicuramente giovato differenziarsi
dalla concorrenza puntando su un fs che ha fama di essere più veloce di
ext3.

 livello piu` vicino a Red Hat
Era troppo impegnata a siglare l'accordo con Microsoft, che per loro
rappresenta il fattore decisivo che dovrebbe spingere i gonz..gli utenti a
usare SuSE.
-- 
Per rispondermi, sostituisci a nomecognome il mio nome e cognome
To reply me, substitute nomecognome with my real name and surname
http://bitsandchaos.wordpress.com

 Mi spieghi qual'e' l'onere derivante dall'uso di reiser o di xfs?
Quando tutto funziona, nessun onere. 


 sbaglia ubuntu e sbagliano tutti gli altri?
Considerato che RH ha circa il 90% del mercato enterprise, direi di si',
Novell sbaglia. E non e' una novita', avevano Netware e sono riusciti a
buttarlo al cesso.


 sarebbero completamente arenati?
In termini di crescita relativa, ext3 e' esploso, visto che e' l'unico che
e' stato supportato da chi ha i soldi ed usato dalla quasi totalita' degli
utenti (finali e professionali).
Gli unici benchmark che ho letto erano quelli su Oracle, in cui ext3 batteva
reiserfs e di molto, per ovvi motivi (molto meno overhead di processore,
c'e' gia' Oracle a fare tutto il lavoro di allocazione dei dati).
Allora, se un utente finale non ha problemi di prestazioni, le applicazioni
web hanno altri colli di bottiglia, i db preferiscono ext3 (o meglio ancora
i raw devices), l'HPC vuole la cosa con meno spreco di processore possibile
(oppure file system molto particolari per gestire dataset immensi), mi sfugge 
l'ambito reale di applicabilita' di reiserfs. Poi se vuoi costruire uno 
scenario X, ci riesci, ma una azienda seria ragiona su grandi numeri, ecco 
perche' RH copre il mercato server, Novell continua a fare cazzate di 
marketing e di ingegnerizzazione, e alla fine passa da reiser a ext3. 


 porrei questi problemi per nulla: sono morti entrambi.
Usi dei raw devices? No perche' a volte mi sembra che tu sia una di quelle
persone che possa permettersi di non dover scegliere, ma solo dire come
avrebbe scelto.


 piace a te.
In effetti, quando poi ti trovi ad avere a che fare con una rete con N
distribuzioni, con ogni macchina che ha un possibile file system, perche'
chi l'ha installato aveva le sue preferenze, ti diverti un sacco. Poi
risparmi soldi, eh.


 
http://lists.opensuse.org/opensuse-factory/2006-09/msg00542.html
Cosa però relativamente recente, mentre RH non fornisce/supporta
reiserfs da un pezzo mi pare..


 chi l'ha installato aveva le sue preferenze, ti diverti un sacco.
Sull'uso di una sola distribuzione sono d'accordo, sull'uso di un solo
file system un po' meno. Per fare un paio di esempi, XFS e` ottimo per i
file server, non fosse che per il fatto che ha la gestione delle quota e
delle ACL embedded; mentre JFS e` quello che attualmente meglio si
adatta alle macchine virtuali, in quanto occupa meno risorse rispetto
agli altri
Enrico

 saprei dire pero` sulla versione commerciale)
In effetti, nella fase di upgrade a Fedora 9, ho visto dei processi jfs* e
xfs* che sono una novita'. Se comunque uno vuole usare altri file system,
puo' fare un pensiero a Scientific Linux, che li compila come moduli.


 Novell invece ha sfondato nel mercato desktop enterprise
In cui il filesystem che usi e' relativamente importante, e di quello stiamo
parlando nel thread.


 agli altri
Xen o Vmware ti certificano JFS?


 dai.... adesso non autoconvincerti troppo che EXT3 e' il migliore. 
Dipende dalla definizione che dai di migliore, e comunque se non e'
certificato e' inutile discuterne per qualsiasi implementazione che non sia 
sul pc di casa. 
http://zork.net/~nick/mail/why-reiserfs-is-teh-sukc
che spiega perche', per scelta progettuale, ext3 non sara' mai molto
performante, ma in compenso assai sicuro, che e' la cosa che conta di piu'
in un fie system.


 consiste questo sviluppo attivo.
Con il fatto che esiste ext4, che e` una diretta evoluzione di ext3, che
a sua volta e` una diretta evoluzione di ext2? Intendiamoci, ext4 non e`
qualcosa nato da zero tipo ReiserFS o Btrfs, ma e` qualcosa che parte da
una base ben definita (ext3) e portata avanti con in mente di farla
evolvere (e non di fossilizzarla ad uno stato noto per ripartire da zero
con altro)
Enrico

 eppure mancano ancora gli extent.....
Adamo, con un file system basato su inode il pc esplode? No, perche`
dovresti avvertire tutti quelli che fino ad oggi hanno usato un file
system basato su inode del rischio che corrono...
Seriamente, qual e` il problema del non avre gli extent? I limiti? Le
performance? Le funzionalita`? Per i primi, tutto dipende da cosa devi
fare. Sicuramente in ambito casalingo difficilmente mi capitera` di
creare un file da 2TB e di avere un file system piu` grosso di 16TB
(anche se a questo poco a poco ci stiamo arrivando), mentre per il
numero di file contenuti in una directory tutto dipende da come formatto
(ma, con le impostazioni di default, il limite e` abbastanza alto da non
preoccuparmi troppo). Per le performance, dove sono i problemi? Ext3,
tra i vari tuning, implementa l'uso di indici di tipo H-Tree, che puo`
essere abilitato o meno (dipende sempre da cosa si deve fare). Per
quanto riguarda invece le funzionalita`, queste sono del tutto
indipendenti dalla metodologia di allocazione utilizzata
Enrico

 Mi dici quindi in cosa consiste questo "sviluppo iperattivo" di ext3?
In ext3, oltre a 3 tipi distinti di journaling, sono stati sviluppati il 
dir_index (che usa una variante di B-Tree per l'indicizzazione delle 
directory, per recuperare lo svantaggio prestazionale con reiser), il 
filetype, per memorizzare il tipo di file direttamente nel fs senza 
bisogno di mime magic (poi sfruttato da nessuno, ma c'e`), lo 
"spargimento" dei superblock sul disco per sfruttare meglio i dischi 
grandi.
Buona parte di queste caratteristiche, e diverse altre ottimizzazioni 
sulle prestazioni, sono state sviluppate dopo il rilascio iniziale di ext3.
Bye.

 extenti, e' perche' btrfs ha gli extent?
Perdonate l'ignoranza, non sapevo cosa fossero gli extent e ho guardato su 
Wikipedia (magari non precisissima).
Da quel che ho capito non e` altro che un modo per preallocare su disco un 
tot di spazio, riservato a un certo file, in modo contiguo, per evitare la 
frammentazione.
Ma c'e` qualche applicazione che sfrutta questa caratteristica?
Su open() e fopen() non c'e` la possibilita` di specificare le dimensioni 
del file, che io ricordi. Penso che siano necessarie syscall apposta.
Bye.

 Ma c'e` qualche applicazione che sfrutta questa caratteristica?
Gli extent sono un concetto applicato nei db ad alte prestazioni.


 Tutto qui.
Hai letto alla rovescia: ext3 non e' performante perche' evita, per scelta,
delle ottimizzazioni che possono essere rischiose in caso di perdita di
alimentazione elettrica.


 (xfs_fsr per xfs, e ext4 avra' pure il suo).
Stronzate, FAT ha i suoi tool di deframmentazione, Ext2 ha un suo tool
di deframmentazione, mentre JFS non ha alcun tool per la deframmentazione
Enrico

 po' scadente. Non ti seguo.
Se mi serve un'auto, devo per forza acquistarmi una spider? Oppure
guardo quali sono le mie esigenze e decido di conseguenza?
Enrico

 Tramite extent si e' risolto questo problema.
Ok, spiegami come mai esiste un defrag per ext2 e sono sempre esistiti
defrag per FAT e NTFS
Enrico

 Non ve ne potete uscire con queste cose .... 
Che due coglioni. Oracle usa gli extent come rappresentazione intermedia
dello spazio disponibile su disco, tutto viene fatto non solo per
consentirti di dire che ext3 fa schifo (abbiamo capito il tuo punto di
vista, ci fossero dei numeri capiremmo anche quelli) ma per migliorare la
gestione dello stesso, visto che e' possibile chiedere ad Oracle di fare
tutte cose sugli extent. 


 Xen o Vmware ti certificano JFS?
Ho capito cosa intendi. Purtroppo i sistemi di virtualizzazione
certificano il funzionamento solo di alcune distribuzioni[1], e quindi
sono soggetti ai limiti/scelte che le distribuzioni si portano dietro.
Rimane comunque un fatto oggettivo (dimostrato da parecchi test piu` o
meno indipendenti) che JFS e` il file system che grava di meno sulle
performance del sistema, e come tale si candida a pieno diritto come
file system preferenziale per le macchine virtuali
Enrico
[1] anche perche` certificarle tutte equivarrebbe ad un bagno di sangue

 Abbiamo gia' detto diverse volte che JFS non ha alcun tool
Ma e` un file system con extent, e da quello che dici *dovrebbe* avere
un deframmentatore
Enrico

 Se la spider ti consuma la stessa benzina e la paghi uguale?
Non consumano la stessa benzina, altrimenti non si spiegherebbero le
differenze di carico della cpu rispetto a JFS
Enrico
P.S. piu` andiamo avanti, e piu` il tuo diventa un palese comportamento
da troll. Se vogliamo continuare a discutere, per favore, smettila

 Non ti sforzare perche' nemmeno tu sai rispondere ;)
Forse perche` bisogna aggiungere delle apposite chiamate di sistema, e
per farlo hanno preferito aspettare ext4?
Enrico

 [1] anche perche` certificarle tutte equivarrebbe ad un bagno di sangue
VMWare addirittura non ha problemi se uno usa NFS:
www.vmware.com/files/pdf/storage_protocol_perf.pdf


 Finalmente ext3 ha B-Tree .... dopo anni che c'era gia' in reiser.
Quindi? Ora c'e', ed e' usabile. Conta niente che una volta non c'era, qui
parliamo di cosa si usa *oggi*, non della splendida storia dello splendido
Linux e di quanto ReiserFS sia stato ingiustamente trattato.
