Newsgroup: it.comp.os.linux.sys
Titolo: jfs per linux: stabilita`, controindicazioni, ...?

Salve,
ho scaricato il filesystem jfs per Linux e, visti i problemi di reiser
con nfs, ero intenzionato ad usarlo come fs journaled. Per ora lo sto
sperimentando con un disco "da battaglia", ma prima di metterlo sul
server mi piacerebbe ricevere qualche "conferma" da chi lo sta gia`
usando.
In pratica, qualcuno e` a conoscenza di bug, limitazioni,
incompatibilita` o altro relativi a jfs?
Grazie.
-- 
Signature under rework - Shuriken

 con nfs, ero intenzionato ad usarlo come fs journaled. Per ora lo sto
ma visti quali problemi??
Il sito namesys ha una sezione NEWS fatta apposta per avvertire tutti
delle varie novità, senza necessità di essere iscritti alla mailing
list....
Visto che non lo sapevi adesso lo sai...

incompatibilita` o altro relativi a jfs?
Sono + o - nella tua stessa soluzione, l'ho installato stamattina e sto
facendo esperimenti... (il tutto su una debian installata su vmware).
Ciao
Diego

Sono + o - nella tua stessa soluzione, l'ho installato stamattina e sto
                             ^^^^^^^^^
ehm... situazione!
Ciao
Diego

 con nfs, ero intenzionato ad usarlo come fs journaled.
Hai dato un'occhiata a XFS della SGI? Mi pare in stato piu` avanzato,
anche se ancora non sono riuscito a campilare il kernel patchato...
A risentirci
\  Davide G. Borin
\\ !!Scudo anti-spam attivo!! Togliere le x e "eliminami" dall'indirizzo
\\\_____________________________________________________________________

 ma visti quali problemi??
Nemmeno io li ho mai visti, finora, ma seguo lwn e le news sul kernel,
e si parla di continuo di possibili corruzioni del fs con kernel 2.4, e
che nemmeno col 2.4.3 sono stati corretti.
A dire il vero non ho ancora capito se si presentano solo con knfsd o
anche con nfs user-space (io uso quest'ultimo).
Il sito Namesys l'ho guardato un paio di volte, ma (saro` cieco) non ho
mai trovato notizie riguardanti nfs.
A dire il vero una corruzione di un file l'ho avuta (i sorgenti del
kernel 2.4.2, condivisi su reiser via nfs, scaricati da un computer mi
hanno dato un sacco di errori di compilazione (sempre gli stessi file,
quindi niente problemi hardware), mentre presi da un altro computer non
avevano problemi. Pero` potrebbero essere dovuti al cambio di
processore (prima un P75, ora un Cyrix133), quindi non mi sbilancio
troppo.


 vmware).
io ho avuto un po' di problemi oggi. Ho usato un disco da 540 Mb per le
prove, ci ho copiato la mia home (o meglio, quello che ci stava), e nel
frattempo ci copiavo e cancellavo altre directory (/var e una subdir
del mirror della debian). Contemporaneamente facevo ripetuti lr -lR.
Durante le cancellazioni in massa (con mc) mi dava di continuo errori
di "directory non vuota", anche se gli avevo detto di cancellare anche
le subdir. Infatti ridando lo stesso comando andava avanti e si fermava
piu` avanti.
Con la home (dove ho gli archivi delle ml, la posta, i file di config,
ecc), sia con mc che con rm -Rf mi dava gli stessi errori, finche` alla
fine si e` piantato il rm e il fs. Nemmeno da un altro terminale
riuscivo a dare un ls sul fs, mentre un umount mi dava "device in uso".
Mi sa che aspetta ancora un po' prima di approdare sui miei HD. :)
Sto pensando pero` che non ho fatto le stesse prove con reiser, e mi sa
che le faccio uno di questi giorni. :)
Bye.


 anche se ancora non sono riuscito a campilare il kernel patchato...
Grazie del suggerimento, sto cercando di entrare nel sito (ma con un
56k e il download del kernel 2.4.3 non e` facile :)
Avevo provato a scaricare anche ext3, ma e` solo il kernel completo e
per di piu` in rpm (preferisco i tgz... :)
Bye.


 anche se ancora non sono riuscito a campilare il kernel patchato...
Già, col 2.4.2 sulla mia Slackware-current non ci si riusciva, oggi
scarico le patches per 2.4.3 (0.10test2, credo) e vediamo cosa esce
fuori...
le cmd_tars si compilano e si installano anche se per compilare
xfs_dump ho dovuto spostare roba a mano.
se ricordo bene, nella manpage di mkfs.xfs si parla di una limitazione
della dimensione massima di un blocco a 4096 contro i 64k previsti, ma
io ho riscontrato un limite a 32k, come stanno davvero le cose?

 piu` avanti.
E' un "bug" noto dall'estate del 2000 ( circa ! ). Metto la parola "bug" 
tra viorgolette perche sembra essere un problema di compatibilita' tra "rm 
-rf" & JFS. 
JFS si organizza i file contenuti in una directory in un albero bilanciato. 
Quando man mano vengono cancellati dei file l'albero si "ribilancia".
Il problema sembra essere il seguente: il comando "rm -rf" apre la 
directory, legge quale e' il primo file, lo elimina e "passa al 
successivo". Questo "passa al successivo" purtroppo non garantisce che, in 
seguito alla riorganizzazzione dell'albero, prima non rimanga qualche file.
Bisognerebbe sapere cosa specifica la semantica POSIX.
Comunque il "classico" "find . -type f | xargs rm -f" dovrebbe funzionare 
...

io ho riscontrato un limite a 32k, come stanno davvero le cose?
Perdonate, credevo che la limitazione fosse su mkfs.xfs, ma riuscire a
creare il filesystem non significa riuscire a montarlo... confermo
4096.
Ritornando a JFS della IBM,
ho provato a compilare gcc-2.95.3 in una partizione formattata JFS su
/dev/hdb5 -> 1m56s il configure, 50m52s il make bootstrap
(il sistema 2.2.19 (ex Debian 2.2.16) su /dev/hda6, un piccolo swap su
/dev/hda5 di 30 MB e un grande swap di 256 MB su /dev/hdb3)
mentre sistema e sorgente su una partizione ext2 (Slackware-current
con kernel 2.4.3) su /dev/hdb6 e swap unico su /dev/hdb3 hanno
totalizzato -> 2m1s, 66m10s
mentre /dev/hdb6 formattata XFS e praticamente con lo stesso sistema
di /dev/hdb5 opportunamente modificato con devfs e kernel
Linux-2.4.3-XFS (31032001) ha totalizzato -> 2m8s, 58m8s
l'attendibilità lascia il tempo che trova, ma mi serviva un'idea per
il sistema da adottare in futuro e cosi' ho cercato di trovare uno
straccio di criterio per scegliere.
JFS sembra favorito, ma è stato quello testato nelle condizioni più
diverse (sistema su 2 dischi, kernel 2.2).
Se ricordo bene un po' di tempo fa' ero riuscito a fare configure e
make per il gcc-2.95.2 in 45 minuti con la Slack motorizzata 2.2.18
Ancora una volta tutto questo ha poco senso visto che di solito si
pensa alle prestazioni dei database server o forse dei news-server.

Ritornando a JFS della IBM,
no, non č stabile, con la 0.2.2 ho visto un bel "Filesystem dirty but
marked clean.... unpredictable", quindi XFS al momento potrebbe essere
il piů stabile tra gli sperimentali.

 il piů stabile tra gli sperimentali.
Peccato che non riesca a compilarlo, almeno con il gcc 2.95.3, che dicono
funzioni...


 dicono funzioni...
Io l'ho compilato con l'egcs.. e funziona: dai un occhiata qua:
http://lupo/articoli/filesystem.html

 
http://lupo/articoli/filesystem.html
hem ...  
http://lupo.campus.uniroma2.it/articoli/filesystem.html