Newsgroup: it.comp.os.linux.sys
Titolo: journaling filesystem su home pc: vantaggi ..

..a parte quelli noti? Oppure per un portatile utilizzato per puro 
diletto da utente singolo e senza problemi hw e sw rilevabili 
(un crash in un anno pacioccando da root con IRDA) sarebbe come 
sparare con un cannone ad una formica? ;)
Se proprio, invece: ext3 o xfs ?
(RedHat 7.1 pesantemente rimaneggiata e 2.4.12)
-- 
	dino

 Se proprio, invece: ext3 o xfs ?
Se ultimamente non ci sono state delle grosse rivoluzioni, EXT3 è ancora
instabile, mentre XFS per Linux è stabile .... inoltre (cosa non da poco),
XFS è stato ampiamente testato per oltre 6 anni su Irix, mentre sia
Reiser, sia EXT3 sono ancora molto "giovani".
-- 
+-------------------------------------------------------------+
|    ~Massimiliano ADAMO      | Yahoo!Messenger: quetzalco_it |
| maxadamo [at] iol [dot] it  | ICQ# 103417788                |
+-------------------------------------------------------------+

 Se proprio, invece: ext3 o xfs ?
xfs
Ciao, `matte.
-- 
err: signature too big

 instabile, mentre XFS per Linux è stabile ....
parole grosse ;-)
Io l'ho provato su un server con squid e non ha retto (kernel panic!!!),
dove reiser è una scheggia.
XFS e JFS hanno avuto il grande pregio di smuovere le acque e far
circolare delle idee ma non ritengo siano davvero utili per la stra -
stra grande maggioranza dell'utenza (anche ad alti livelli).
Che ne dite ?

  Se proprio, invece: ext3 o xfs ?
Reiserfs, se il sistema ti va` bene cosi` allora ext3
Se ti interessa sapere come convertire la partizione da ext2 a ext3:
se ne parlava in un thread qualche giorno fa`
Ciao, Andrea
-- 
          (o_  | 
(o_  (o_  //\  | Andrea Carosi, just another Linux user
(/)_ (/)_ V_/_ |
GnuPG PK fingerprint: 0857 1927 150B 3C8E 8274  F641 1388 AA6D 3FA0 5410

  EXT3 č ancora instabile
   ^^^^^^^^^^^^^^^^^^^^^^^
Tanto instabile che sara` possibile utilizzarlo nell'installazione della
prossima RH


  Che ne dite ?
Che hai ragione, ma sono comunque fs interessanti & da provare
Ciao, Andrea (che si ripromette da un mese di provare jfs...)


 
ed è già disponibile durante l'installazione di Mandrake 8.1

 prossima RH
io non mi fiderei ad installarlo, solo perche' lo fa RH, guarda che
casino hanno combinato con il gcc, se invece fosse messo da Debian
(stable)...
-- 
 ___     | (o_
 |_|     | //\
 | |ndry | V_/_ Linux Newbie (quasi User :-) ), RH 7.1 (Seawolf)
         |        Linux User #221457

ed ? gi? disponibile durante l'installazione di Mandrake 8.1
E dalla 6.5 di Turbolinux 
Ciao.
-- 
Zio Ciano.

 (stable)...
Sono state inserite le patch per l'ext3 nella woody. Non so i dischi di
installazione se ce l'abbiano, ma tra i pacchetti installabili c'e` (e
anche i driver nVidia... :)
Bye.

 Io ti dico la mia.Usalo.
Mi associo.
Ciao.
-- 
***  Per E-mail rimuovi ModE dall'indirizzo  ***
  *** Linux user # 198661 --- ICQ 33500725 ***
*** homepage 
http://web.tiscalinet.it/kailed
 ***
            *** Powered by Linux ***

 - ICQ# 92905138
http://www.mascanc.net/~skolem

  (stable)...
"Boot-floppies 3.0.14 released. Adam Di Carlo has had a hectic week,
but managed to [6]release a new version of boot floppies. This
version contains all required fixes for S/390, MIPS, MIPSel, ARM,
M68k, HPPA and IA64 as well as patches required to get add support for
ReiserFS and ext3 on IA32. [...]
6. 
http://lists.debian.org/debian-boot-0109/msg00365.html
Da "Debian weekly news" del 3 ottobre


Reiserfs, se il sistema ti va` bene cosi` allora ext3
Ho ricompilato e copiato l'intero sistema sulla nuova
partizione Reiserfs che sto' usando ora.
Due problemi: non riesco ad installare lilo nella mbr ma 
solo su floppy ed allo spegnimento la redhat pare
non smontare correttamente la root.
Ora vo' a spulciare tra le FAQ che ovviamenete non ho letto :)  
-- 
	dino

 (RedHat 7.1 pesantemente rimaneggiata e 2.4.12)
anche io ti dico la mia ,su una macchina con la tua stessa RH71 e
kernel, xfs è decisamente 
+ veloce nella copia/lettura di grosse directory, e di grossi file in
genere.reiser è + veloce a copiare 
spostare cancellare leggere file di piccole dimensioni....dati alla
mano...non fidarti dei bench trovati in rete
qua e la.ciao.

 prossima RH
i maligni potrebbero dire: appunto  :))
(ok, ok, era una battuta)
-- 
addio, e grazie per tutto il pesce

 anche i driver nVidia... :)
cmq, se l'ha messo debian tra i suoi pacchetti, abbiamo una prova
ulteriore della bonta' di ext3, quasi quasi ci faccio un pensierino :-)


ulteriore della bonta' di ext3, quasi quasi ci faccio un pensierino :-)
Sisi, fai la cavia, che poi se ne val la pena mi associo :)
-- 
           ~~ ICQ#: 8761263 ~~ 
http://www.delymyth.net/
 ~~
            E-Mail Addy: DElyMyth [at] delymyth [dot] net
           => FREE! Hardware Anti-Virus!!! - /dev/brain <=
Chi lavora avvelena anche te, digli di smettere - DElyMyth@work

 leggere file di piccole dimensioni...
Confermo questi risultati con la mia esperienza. XFS e` piu` veloce nella
maggior parte dei test "pratici".
A risentirci
\  Davide G. Borin
\\ !!Scudo anti-spam attivo!! Togliere le x e "eliminami" dall'indirizzo
\\\_____________________________________________________________________

 Se proprio, invece: ext3 o xfs ?
ext3 con i kernel <= 2.4.9 o gli ultimi della serie -ac è considerato 
stabile; non è garantito  il journaling della quota, e il funzionamento del 
journaling con i sistemi raid ( troppi strati software, ognuno dei quali 
scrive quando vuole ... ). Il suo grande vantaggio è la facilità di 
migrazione da ext2->ext3 e viceversa in caso di necessità.
xfs *sembra* un po' più testato, ed ha le acl, oltre che alcune feature 
interessanti ( tipo quella che garantisce un banda predeterminata tra il 
filesystem e l'applicazione !! ). 

 ulteriore della bonta' di ext3, quasi quasi ci faccio un pensierino :-)
Io l'ho usato con potato e i pacchetti di bunk per il kernel 2.4 fin
dal kernel 2.4.7 (ora ho un 2.4.10) e non mi ha mai dato problemi.
Un paio di giorni fa mi si era piantato il kernel con un errore di ext3
e sono stato colto dal panico, poi mi sono accorto che era il cavo di
alimentazione dell'hd che con le vibrazioni tendeva a staccarsi... a
computer acceso ho tolto il cavo di alimentazione dell'hd e ne ho messo
un altro e ha ripreso a funzionare tutto tranquillamente. Lo so, sono
un pazzo.  :)))
Bye.

  non smontare correttamente la root.
Mah, mi pare strano, in ogni caso non uso RH e quindi non so come sono
organizzati gli script per lo shutdown


 Sisi, fai la cavia, che poi se ne val la pena mi associo :)
Io ho  appena messo l'ext3,  per adesso non  ho avuto alcun  problema di
stabilità... vedremo in  seguito. Pittosto, non mi  convincono troppo le
prestazioni. Con  un breve  benchmark (?) con  hdparm sembrerebbe  che i
risultati siano ridotti  di 1/3 rispetto all'ext2, ma non  so fino a che
punto siano attendibili.  Tra l'altro, la doc  ufficiale dell'ext3 parla
di un aumento di prestazioni rispetto all'ext2... mboh.
-- 
 .-=-.    .-=-,    .-=-,     (^)      -@)      (@<      ( )      (@<
(     )  (  ,' )  (  ,^ )  (`\~/')  (\(~)/)  (\(~)/)  (\(~)/)   (< )
 ~-=-~    ~-=-~    ~-=-~    ~-=-~    ~-=-~    ~-=-~    ~-=-~     ^^
Filippo Panessa A.K.A. Kalem | --== Powered by Debian Gnu/Linux ==--

 un pazzo.  :)))
e xche`? io ho staccato il chip del bios a caldo (AKA a macchina avviata)
e ne ho messo un altro da riprogrammare... ma micca sono pazzo!!! :-)
--
ciao, Mirco.
[ Icq#:51640305 ] [ 
http://www.quasarbbs.net/mircomir/
 ]

 e ne ho messo un altro da riprogrammare... ma micca sono pazzo!!! :-)
sicuro sicuro che tu non abbia qualche problemino :)


 quindi non su Potato :-)
E` ovvio. Quando e` uscita la potato la patch piu` recente per ext3 era
la 0.0.7a e non penso che era stabile al 100% . Inoltre considera che
ora lo sviluppo di ext3 viene portato avanti su kernel 2.4, che
nativamente non gira su potato 
Henryx
-- 
A Gennaio, durante l'uscita del kernel 2.4.0, Linus Torvalds disse: "Da
ora in poi la versione stable del kernel sara` quella con il minor number
dispari"

 Mi associo.
Mi ricordo che scartai ReiserFS perche` non ti permetteva di scegliere
la dimensione del journal. E` cambiato qualcosa?
Henryx
-- 
A Gennaio, in occasione dell'uscita del kernel 2.4.0, Linus Torvalds


 sicuro sicuro che tu non abbia qualche problemino :)
Sicurissimo, l'ho fatto anch'io, e sia il donatore che il trapiantato sono,
per quel che ne so ancora in salute.
Ah, per migliorare l'intervento, le due piastre _non_ erano neppure uguali.
Che dici? cio' non prova che lui non abbia qualche problemino, ma anzi che
io... 
Sono malignita', torna a tacchinare, va! ;-)
-- 
           |Save our planet!
  Ciao     |Save wildlife;
  roberto  |For your E-MAIL use only recycled Bytes !!
           |roberto poggi  
rpo...@softhome.net

 Reiserfs, se il sistema ti va` bene cosi` allora ext3
Basta con questa pubblicita` regresso :-)))
Ciao, `matte.
-- 
err: signature too big

 Ah, per migliorare l'intervento, le due piastre _non_ erano neppure uguali.
beh, chiaro che erano diverse: una Asus P2l97 e una MSI6119 :-)
Purtroppo il bios della MSI mi si e` sputtanato durante un aggiornamento...
Preso il chip, avviato con la P2L97 staccato il suo, messo quello della 6119
e provato a riprogrammare... Scrive... ma poi quando verifica la prima locazione
era a 0xFF (eprom cancellata) invece che 0x...  Suppongo che il chip fosse bruciato drante
la programmazione sulla sua scheda. Non mi era mai capitato una osa del genere.
Ad ogni modo, spendo la macchina, rimesso il bios alla Asus che ora e` la mia scheda madre...
PS: le 2 eprom erano entrambe dei winbond (stessa sigla) quindi se il chip fosse stato
OK la scrittura doveva avere successo.


 writes:
Filippo> Io ho appena messo l'ext3, per adesso non ho avuto alcun
Filippo> problema di stabilità... vedremo in seguito. Pittosto, non mi
Filippo> convincono troppo le prestazioni. Con un breve benchmark (?)
Filippo> con hdparm sembrerebbe che i risultati siano ridotti di 1/3
Uh? hdparm non passa sul filesystem per fare i suoi test. Con -tT si
passa dalla cache (RAM) e dal disco (direttamente).
Se vuoi provare il filesystem in presa diretta puoi fare un dd:
$ time dd if=/dev/zero bs=1024k count=100 of=file.tmp
entrati 100+0 record
usciti 100+0 record
real	0m4.007s
user	0m0.000s
sys	0m1.040s
Circa 25MB/s qui su reiserfs in notail. Per un test più serio si provi
bonnie++ o una copia di directory e file di media grandezza.
Ciao
Marco

sys	0m1.040s
Beh il mio buon vecchio ext2 vi polverizza:  ;-))
$ time dd if=/dev/zero bs=1024k count=100 of=file.tmp
100+0 records in
100+0 records out
real	0m0.019s
user	0m0.000s
sys	0m0.000s
1000+0 records in
1000+0 records out
Ma scrivo per qust'altro motivo: dipende dalla cache?
Infatti se subito replico, ho:
100+0 records in
100+0 records out
real	0m0.005s
user	0m0.000s
sys	0m0.000s
E cosi` a 5 millesimi anche tutte le successive volte, a parte un 4
millesimi isolato. Qual e` il tempo vero?
-- 
Ci sentiamo  |  Remigio Zedda  || Attenzione! campo "From:" alterato
ciao Remigio |                 ||==> E-mail: 
remi...@tiscalinet.it
-------------|      ..si` d'accordo.. ma con la Deb e` un'altra cosa!
/* Linux 2.2.19pre17 su Debian GNU/Linux 2.2 Potato */

 bonnie++ o una copia di directory e file di media grandezza.
Perche` bs=1024k e count=100?
Non sarebbe meglio bs=1k e count=100k?
Inoltre suggerirei anche il contrario:
time -p dd if=file.tmp of=/dev/null bs=1k
bye,
-- 
  Piergiorgio Sartor

 Infatti se subito replico, ho:
Certo, il file creato sta in memoria, se vi riscrivi sopra,
lui scrivera` prima in memoria e poi, con comodo, su disco.
bye,
-- 
  Piergiorgio Sartor

lui scrivera` prima in memoria e poi, con comodo, su disco.
E dunque il tempo del disco qual e`? Il primo o nessuno?


>>>>> "PS" == Piergiorgio Sartor <sar...@sony.de.REMOVE.THIS> writes:
PS> Perche` bs=1024k e count=100?
PS> Non sarebbe meglio bs=1k e count=100k?
Diciamo che, in questo modo l'overhead indotto da dd sarebbe troppo:
centomila read che impatterebbero parecchio sul risultato finale a
causa del carico indotto sulla CPU. Forse un blocco da un mega è un
po' troppo, ma almeno si dovrebbe essere più sicuri che - ove
possibile - si usino i meccanismi del kernel per leggere più blocchi
alla volta. A causa dei buffer di lettura/scrittura sui dischi la
scelta migliore sembra essere una dimensione di qualche decina di
KB. I risultati sono simili specie i tempi reali, ma si nota però
l'ovvio cambio di occupazione della CPU.
Le riprove in scrittura (con ~128MB liberi e destinati a cache):
+ bs=1k count=200000
real 7.93
user 0.14
sys 3.93
+ bs=10k count=20000
real 7.16
user 0.03
sys 2.33
+ bs=100k count=2000
real 7.15
user 0.01
sys 2.16
PS> Inoltre suggerirei anche il contrario:
PS> time -p dd if=file.tmp of=/dev/null bs=1k
Certo, il mio non voleva essere un test completo o veritiero.
$ time -p dd if=file.tmp bs=100k count=2000 of=/dev/null
entrati 2000+0 record
usciti 2000+0 record
real 8.34
user 0.01
sys 1.30
Ciao
Marco

 writes:
rez> Beh il mio buon vecchio ext2 vi polverizza:  ;-))
Qui (ATA100) ecco un ext2 vs. reiserfs (throughput, dato di per se
poco significativo credo):
ext2$ time -p dd if=/dev/zero bs=100k count=2000 of=file.tmp
entrati 2000+0 record
usciti 2000+0 record
real 10.46
user 0.02
sys 1.78
reiserfs$ time -p dd if=/dev/zero bs=100k count=2000 of=file.tmp
entrati 2000+0 record
usciti 2000+0 record
real 7.15
user 0.01
sys 2.16
rez> Ma scrivo per qust'altro motivo: dipende dalla cache?
A parte il tuo errore (ho letto l'altro messaggio) bisogna usare
dimensioni più grandi della cache che hai (meglio stare più larghi di
ram-size se si può).
Ciao
Marco e ora tutti di filata a installare bonnie++

 E dunque il tempo del disco qual e`? Il primo o nessuno?
In questo caso non vi e` molta differenza fra
il primo ed il secondo... Direi, forse il 5%?
Comunque, come scritto altrove, e` bene usare file
di dimensioni superiori alla RAM disponibile,
oppure occupare tutta la RAM in qualche modo :-)
bye,
-- 
  Piergiorgio Sartor

 l'ovvio cambio di occupazione della CPU.
Non sono al 100% d'accordo, diciamo al 90% :-)
Se vuoi evitare l'overhead di "dd", allora meglio
qualcosa come bs=100m count=1 (anche se inutile,
alla fine dei conti, ma sicuramente piu` "formale").
Secondo bisogna vedere come si comporta il sistema
nei casi "normali".
Esempio: "cp pippo pluto" come copia? Usa blocchi da 1k,
usa blocchi grandi quanto "pippo"?
E quando lancio, per esempio, SOffice (un mattone) come
viene caricato il codice? In un sol colpo? Per blocchi
di 1k? E quando faccio, per esempio,
"xv pamela_2048x1536_very_hi_quality.jpg" come viene caricato
il file? In un colpo? Per blocchi di 1k, per byte?
E cosi` via...
Insomma bisogna vedere come nella realta` il filesystem
viene usato, per poter poi estrapolare un test.
Naturalmente mi e` chiaro che il tuo era solo un
esempio e non aveva la pretesa di essere un
benchmark esatto.
bye,
-- 
  Piergiorgio Sartor

 $ time dd if=/dev/zero bs=1024k count=100 of=file.tmp
Questi sono i risultati (non vi spaventate, ho un HD molto lento):
*ext2*
real    0m17.417s
user    0m0.000s
sys     0m2.700s
*ext3*
real    0m14.870s
user    0m0.000s
sys     0m2.780s
Stasera install bonnie++ e faccio delle prove più approfondite.


 Sono malignita', torna a tacchinare, va! ;-)
gia fatto :-)
PS che fai, ti fai vedere Sabato sera? 


 nativamente non gira su potato 
effettivamente, mi sono dimenticato che i pacchetti in test, non ce li
mettono neanche morti sulla Potato :-/
Un Andry in OverDose da distribuzioni %-/


 (root)
Tagliamo la testa al toro. Lunga vita a GRUB!
--
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.mascanc.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
  -<! Take It All, Our Gold, Our Homes, Our Life, 
  		But We Didn't Kill Your Christ! !>-
  			Blind Guardian - The Script For My Requiem

 di 1k? E quando faccio, per esempio,
Il tempo di caricamento di StarOffice dipende dal "load" delle librerie.
In realtà le "librerie" non si caricano, ma si mmap-pano ( man mmpa(2) ); 
in effetti è una cosa un po' diversa dalla read, e bisognerebbe di un test 
a parte; ma ci sono anche problemi di rilocazione, che pesano più del 
mmap-pamento vero e proprio; sulla mia macchina ( che ha 382M ) al secondo 
load non legge niente dal disco, perchè ha tutto in memoria, ma ci impiega 
lo stesso del tempo.
Il processo di mmap probabilmente è fatto a blocchi di 4k ( tale è la 
dimensione fisica di una pagina ).

 Sisi, fai la cavia, che poi se ne val la pena mi associo :)
Kernel 2.2.19
Patch: 0.0.7a
Mai avuto nessun problema :PPP


 Beh il mio buon vecchio ext2 vi polverizza:  ;-))
Ext3 e cache vuota (aveva appena finito di suonare mpg123)
$ time dd if=/dev/zero bs=1024k count=100 of=file.tmp
100+0 records in
100+0 records out
real    0m25.857s
user    0m0.000s
sys     0m3.690s
Cmq imho dipende anche dall'hd (da me Quantum Bigfoot 4Gb) e dalla 
posizione della partizione ( /tmp si trova su /dev/hda8 )


 time -p dd if=file.tmp of=/dev/null bs=1k
Fatto:
[henryx@artemide]/tmp $ time -p dd if=file.tmp of=/dev/null bs=1k
102400+0 records in
102400+0 records out
real 21.70
user 0.06
sys 4.81
[henryx@artemide]/tmp $


posizione della partizione ( /tmp si trova su /dev/hda8 )
Cavoli 6x + lento:-((
Il bigfoot era famoso perche' enorme (per quei tempi) ma lento, era per
grosse moli di dati.
E poi sei a pio mode 4, neppure l'accesso diretto alla memoria, o
ricordo male?
Ahh pero` potrebbe dipendere dall'ext3..  O:-)


 copy only BLOCKS input blocks
Mah, a casa mia funziona... Non capisco
perche` non dovrebbe, dalla man page.
Cioe` 100k blocchi di 1k equivalgono
a 100 blocchi di 1m, in termini di memoria.
Diverso discorso per l'overhead del task
scheduling di "dd", come fatto notare altrove.
bye,
-- 
  Piergiorgio Sartor

  Tagliamo la testa al toro. Lunga vita a GRUB!
Momento, il lilo aggiornato serve per comodita`, si puo` usare anche una
versione vecchia, basta dare "mount -o remount,notail /" e copiare
bzImage in /boot, solo che se lo fai da newbie e non ti parte piu` linux
(e non hai un disco/partizione di rescue...) allora sono caxxi amari...
Ciao, Andrea
-- 
          (o_  | 
(o_  (o_  //\  | Andrea Carosi, just another Linux user
(/)_ (/)_ V_/_ |
GnuPG PK fingerprint: 0857 1927 150B 3C8E 8274  F641 1388 AA6D 3FA0 5410

 dimensione fisica di una pagina ).
s/probabilmente//
:-)
--
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.mascanc.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
  -<! Heavy Metal Or No Metal At All! Whimps And Posers Leave The Hall !>-
 	 			Manowar - Metal Warriors

 Ahh pero` potrebbe dipendere dall'ext3..  O:-)
:PPP
Come gia` detto imho dipende anche dalla posizione della partizione e
dal tipo di hd, per questo motivo sarebbe piu` veritiero un benchmark su
di una partizone prima formattata con un file system, poi ricomvertita
in un altro e cosi` via finche` non si finiscono i test


 Basta con questa pubblicita` regresso :-)))
Mmm... ma non eri tu che avevi dei problemi allucinanti con
INN+ReiserFS? <g>


 INN+ReiserFS? <g>
naaa ;-)
Io non ho mai avuto problemi con INN, solo qualche post sul perche` INN
fosse cosi` difficile da recuperare nel dopo-crash. Ma succedeva (anzi
succede) con tutti i FS.... :D


 Marco
-- 
...FreE FrAGs FOr ALl...                                                        
GPQuake Clan Proud Members                                                      
email:ho...@libero.it
 
--------------------------------  

 writes:
HoKuS> io con ext3 e Debian ottengo questo
HoKuS> real 0m0.838s user 0m0.000s sys 0m0.830s
Io con la bicicletta in discesa faccio 70Km/h.
Probabilmente in salita non ci riesco.
Ipotizzo che tu abbia ben più di 100MB liberi/cache RAM e/o che tu
non abbia letto tutto il thread.
Saluti
Marco