Newsgroup: it.comp.os.linux.sys
Titolo: 2.4.3-XFS ok, ma senza debugging

Non ho avuto problemi a patchare il kernel 2.4.3, ma non posso
abilitare il debugging (sempre senza DMAPI o Vnode tracking) perchč la
compilazione non termina. Sulla ML mi č stato suggerito di usare un
gcc-2.91.66, ma sinceramente il fatto che il codice non sia gradito al
2.95.2 mi puzza.
Date un'occhiata perfavore:
xfs_bmap.c: In function `xfs_bmap_del_extent':
xfs_bmap.c:3130: internal error--unrecognizable insn:
(insn/i 
528 527 2172
 (parallel[ 
            (set (reg:SI 0 %eax)
                (asm_operands ("") ("=a") 0[ 
                        (reg:DI 1 %edx)
                    ] 
                    [ 
                        (asm_input:DI ("A"))
                    ]  ("linux/xfs_linux.h") 269))
            (set (reg:SI 1 %edx)
                (asm_operands ("") ("=d") 1[ 
                        (reg:DI 1 %edx)
                    ] 
                    [ 
                        (asm_input:DI ("A"))
                    ]  ("linux/xfs_linux.h") 269))
        ] ) -1 (insn_list 495 (nil))
    (nil))
cpp: output pipe has been closed
make[3]: *** [xfs_bmap.o] Error 1
make[2]: *** [first_rule] Error 2
make[1]: *** [_subdir_xfs] Error 2
make: *** [_dir_fs] Error 2

 2.95.2 mi puzza.
Io su debian 2.2r0 ( gcc 2.95.2 ) ho compilato il kernel 2.4.0 con la patch 
per l'xfs ( non ricordo la versione, ma voleva il kernel 2.4.0 ). La 
compilazione e' andata a buon fine, ma durante l'uso il programma di test ( 
bonnie++ ) si e' bloccato, e neanche kill -9 lo sbloccava. Andandomi a 
leggere le informazioni sul sito ( le FAQ ) ha confermato il problema con 
il gcc 2.95.2. Sembra  che con il 2.95.3 il problema non sussista piu' ( ma 
vallo a trovare ... ) 

2.95.2 mi puzza.
Mamma Slackware pensa proprio a tutto, ho installato egcs e linkato
kgcc a egcs-2.91.66 e come per magia il 2.4.3-XFS con tanto di DEBUG
attivato si è compilato (DMAPI e Vnode tracking disabilitati)
Sto preparado una sorta di mini-bench basato sulla stupidissima
compilazione delle qt-2.3.0 su un sistema Slackware (scaricata ridotta
all'osso e allargata a suon di compilatore, con kernel 2.4.3) clonato
su 3 partizioni di un Quantum Fireball Plus AS da 20.5 GB (/dev/hdb)
i sistemi sono pressochè identici, differenziandosi solo per il
filesystem su cui si trova la / e kernel con supporto "statico" per il
filesystem della /
ovviamente sarà più leggero il kernel con supporto per ext2 e gli
altri saranno "appesantiti" dal supporto per ext2
L'unica accortezza che mi è venuta in mente è quella di usare una
piccola partizione di swap su /dev/hda per evitare che nel caso di una
"swappata" sia avvantagiata la partizione fisicamente più vicina a
quella di swap.

daed...@freemail.it
 wrote:


Anche io sto vorrei fare dei piccoli benchmarch fra i FS in voga:
reiserfs
ext3
jfs
xfs
Ti va di coordinare il lavoro ?

Ti va di coordinare il lavoro ?
Certamente, qualcosa si puo' fare insieme.
Devo aggiungere che E' POSSIBILE compilare anche il codice di
debugging avendo l'accortezza di usare gcc-2.95.3 come kgcc (2.95.2
non va)
Posso dirti che ho già fatto alcune prove che non mi hanno molto
soddisfatto:
JFS-0.2.2
XFS-040120001
reiserfs distribuitocol 2.4.3
per ext3 la vedo dura, non so da dove cominciare, ho visto i pacchetti
sul sito della RedHat, ma non ho capito se il kernel va patchato e
dove si trova la patch.
vi racconto quel che ho fatto tra venerdi' sera e sabato:
ho installato una Slackware alla meno peggio con quello che vedi su
http://village.flashnet.it/fn048069
ho tartassato il mio povero Quantum Fireball Plus AS 20.5GB:
ho costruito un sistema in grado di compilare il kernel su /dev/hdb2
ho preparato il sistema per partire o con  un kernel "supportJFS" o
con un kernel "supportXFS" (con il solo enable XFS Debug attivato)
e un kernel "Linux" con supporto statico per reiserfs (senza extra
checking) usando il codice originale non patchato.
Probabile che anche JFS abbia del codice extra di ricerca dei bug che
non puo' essere disabilitato via "menuconfig"
ho usato devfs e devfsd per evitare problemi con /dev
ho compilato le utilities per JFS in linux/fs/jfs/utils (se ricordo
bene)
ho compilato le cmd_tars di XFS: attr, xfsdump e xfsprogs
anche se in realtà xfsdump è sufficinete perchè contiene mkfs.xfs
ho brutalmente copiato restore (
http://dump.sourceforge.net
) da quello
che uso nella partizione Debian
ho compilato e installato Perl-5.6.0
ho creato un albero xc con il sorgente di XFree-4.0.3
da notare che JFS non carica i moduli compilati per l'originale 2.4.3,
quelli che sviluppano XFS invece si sono resi conto delle
incompatibilità e hanno saggiamente fatto in modo di creare una
/lib/modules/2.4.3-XFS dove si trovano moduli che effettivamente
possono essere caricati.
ho creato diverse partizioni da 2000M: /dev/hdb5, /dev/hdb6, /dev/hdb7
ho creato rispettivamente JFS, ReiserFS, XFS con i rispettivi mk..
sono ripartito con la Debian ho "dumpato" /dev/hdb2 su /dev/hda1
formattata ext2 (in seguito è stata cancellata e usata come swap)
sono ripartito con la Slackware su /dev/hdb2 e ho "restorato" i 621.15
MB del dump montando a turno su /mnt e usando restore rf
/floppy/slackdump (hda1 sarebbe il floppy ;-)
.....
taglio corto e vi sparo alcuni numeri dritti nelle vene e vi prego di
non pubblicarli, considerateli GPL, anche se sono potenzialmente utili
e attendibili come l'aria fritta.
tempo per il restore dei 621.15 MB da /dev/hda1
|                      |  time      used     avaible
+ ---------------------+---------+----------+---------+          
|hdb5 (JFS*)    2039796|3m 58.6s |  619060  | 1420736 |
|hdb6 (ReiserFS)2048188|4m 16.2s |  582980  | 1465208 |
|hdb7 (XFS*)    2043456|5m 44.6s |  609744  | 1433712 |
+-------------------------------------------------------------+
*considerate JFS e XFS come appesantiti da codice di debugging
come potete notare gli spazi impiegati non sono tanto compatibili con
il dato dei 621.15, mah!
cp -a kernel-2.4.3 linux (sempre in /usr/src)
|               |  time        
+ --------------+---------+          
|hdb5 (JFS*)    |1m 34.2s |
|hdb6 (ReiserFS)|1m 35.25s|
|hdb7 (XFS*)    |1m 50.4s |
+-------------------------+
make Everything >& /dev/null (in /usr/src/xc, con partizione di swap
su /dev/hda1 di circa 800MB)
|               |   time      used       avaible
+ --------------+-----------+----------+---------+          
|hdb5 (JFS*)    |107m 11.2s |  874352# | 1165444#|
|hdb6 (ReiserFS)|109m 20.8s |  804180  | 1244008 |
|hdb7 (XFS*)    |108m  4.7s |  873212  | 1170244 |
+------------------------------------------------+
# al riavvio segnava 619120 e 1420676, un bel "Filesystem dirty, but
marked clean" come risultato di un fsck.jfs impartito usando il
sistema su /dev/hdb2
tar -zxf /cdrom/source/web/mozilla-M18.tar.gz
|               | time     used      avaible
+ --------------+-------+----------+---------+          
|hdb5 (JFS*)    |2m 15s |  862408# | 1177388#|
|hdb6 (ReiserFS)|1m 55s |  961912  | 1086276 |
|hdb7 (XFS*)    |3m 37s |  1110084 | 933372  |
+--------------------------------------------+
#qualcosa non va, vedi sopra
Mi scuso per la lunghezza del post... ma non potevo farne a meno.
Ciao!

 Mi scuso per la lunghezza del post... ma non potevo farne a meno.
Non scusarti, questo e` un post molto interessante!
A risentirci
\  Davide G. Borin
\\ !!Scudo anti-spam attivo!! Togliere le x e "eliminami" dall'indirizzo
\\\_____________________________________________________________________

 03212001.
'Azz', mi rispondo da solo: ho letto la data all'europea anziche`
all'americana (maledetti! 8-) )... E` chiaro che la tua versione e`
ancora piu` recente: presa da CVS?


zone. Le prove dovrebbero essere fatte nella stessa partizione.
Caspiterin, caspiterino,
pensavo fosse trascurabile e che l'accorgimento per la partizione di
swap fosse sufficiente.
 
Spero di avere il tempo e la pazienza di ripetere tutto usando la
stessa partizione.

zone. Le prove dovrebbero essere fatte nella stessa partizione.
Caspiterin, caspiterino,
pensavo fosse trascurabile e che l'accorgimento per la partizione di
swap fosse sufficiente.
 
Spero di avere il tempo e la pazienza di ripetere tutto usando la
stessa partizione.
Prima di procedere vorrei sentire qualche altro parere.

 swap fosse sufficiente.
In realta` non ho mai misurato la differenza. Prova a fare un dd e
cronometrare.


 avendo l'accortezza di usare gcc-2.95.3 come kgcc (2.95.2 non va)
Io l'ho compilato con l'egcs della Mandrake.
I miei *primi" risultati sono su
http://lupo.campus.uniroma2.it/articoli/filesystem.html
Su cui ci sono anche dei commenti ....

cronometrare.
Ho ripartizionato il disco e spostato la mia Debian da hda6 a hdb2
ora ho:
hdb1     3GB
hdb2	 3GB
hdb3	 2GB
hdb4	 estesa (enorme e vuota)
ho provato a ripetere qualche volta dd ibs=1M obs=1M count=100
if=/dev/hdb1 of=/dev/null e la stessa cosa per hdb3 e direi che hai
ragione: sembra verosimile una differenza che va da 5-9%, se dovessi
scoprire che è possibile riscontrare differenze di oltre il 10% potrei
avere dei forti scompensi al cuore.
Già ci sono un milione di cose di cui tener conto quando si partiziona
un disco, non puo' essere che uno debba preoccuparsi anche di questo!
Volendo azzardare un'analisi dei dati che ho sparato tenendo come
ipotesi che le differenze dovute alla posizione sul disco della
partizione siano sotto il 10% e nella più completa ignoranza dei
termini tecnici che riguardano i filesystems mi accingo a scrivere:
XFS è più lento in fase di allocazione, perchè usa dei "cassetti" di
dimensioni variabili tra i 4096 e i 512 bytes e questo comporta una
perdita di tempo rispetto a JFS e ReiserFS che usano sempre e comunque
cluster "fissi" da 4096
Commenti, critiche, smentite e ogni altra forma di dibattito sono
oltremodo graditi.

 Su cui ci sono anche dei commenti ....
Articolo interessante e molto utile.
Teniamo anche conto pero` che XFS e JFS sono a 64 bit, mentre Reiserfs e`
a 32 (almeno su x86): per chi necessita di file grossi (per esempio per
video-editing) questa e` una fastidiosissima limitazione (max 2BG per
file). XFS (forse anche JFS, non ricordo) supporta inoltre le ACL, altra
funzionalita` molto interessante, soprattutto per server.
Detto questo, ho fatto un paio di test "real-world" con Reiserfs e JFS
(per l'XFS aspetto di installare il gcc 2.95.3), scompattando il kernel,
copiandolo su un'altra directory e altre cosette simili: postero` i
risultati quando li avro` tutti, ma premetto che JFS si e` dimostrato
spaventosamente lento nella copia e nella cancellazione, a fronte di un
vantaggio piccolo sugli altri test.


 funzionalita` molto interessante, soprattutto per server.
Ho notato che JFS ha grossi problemi man mano il disco si riempie ( ho 
copiato i file da un partizion ad un altra fino a quai riempirla. I file 
erano circa 5 GB e c'ha messo 1 ora. XFS piu o meno gli stessi file c'ha 
messo la meta' del tempo. Devo vedere ancora cosa fa reiserfs ed ext2 )

 messo la meta' del tempo. Devo vedere ancora cosa fa reiserfs ed ext2 )
Ho concluso i miei testi "real world": una scompattazione del kernel, una
sua copia su un'altra directory, un chown -R, un rm -r e un cat di tutti
i file su /dev/null. Il risultato e` che XFS ha prestazioni pari o
superiori a ReiserFS in tutto tranne rm -r (dove credo reiserFS sia
veramente imbattibile!). JFS e` piu` veloce nel primo e nell'ultimo test,
ma enormemente piu` lento nella copia e nell'rm -r (dove ha anche quel
fastidiosissimo bug!).
Da parte mia posso quindi dire che XFS sara` il mio prossimo file system,
anche considerando tutte le funzionalita` che offre (ACL, altributi
estesi, ed altro).


 estesi, ed altro).
beh' la ptach acl esiste pure per ext2 ....