Newsgroup: it.comp.os.linux.iniziare
Titolo: ext2->->ext3 scusate...

Allora, scusate se ritorno su questo argomento gia' consunto, ma come 
dicono da queste parti, meglio aver paura che buscarne (bella morale, sě)
uso una mandrake 8.1 aggiornata poi col tarball del 2.4.18 e da qualche 
giorno sono passato dal kernel 2.4.18 al 2.4.20. 
Avevo giornalizzato con tune2fs la partizione /home ma rimaneva il problema 
della partizione root.
se ho ben capito leggendo i post per montare la partizione di root col 
filesystem ext3 occorre che il supporto per quel filesystem sia incluso 
statico nel kernel, e questo mi sta bene, perche' l' ho compilato cosi'. ho 
anche inserito l' ext2,il ram disk support e l' initial ram disk support 
come built-in.
 
Non ho capito invece se e quando occorra invece ANCHE usare un RAM disk per 
fare il boot: sempre o solo se l' ext3 e' compilato come modulo?
se poi devo creare un RAM disk con mkinitrd, devo anche inserire delle 
opzioni (quando e perche'?) o basta la versione del kernel?
E poi, per fare il boot col ram disk, basta inserire la voce corrispondente
initrd=<name>
 nella configurazione di lilo ? se fosse vero potrei che so, modificare l' 
entry del vecchio kernel e fare un tentativo sicuro (se qlcs va storto, 
riavvio col 2.4.20 e chi s'e' visto s'e' visto)?
ed in ultimo: e' vero che usare tune2fs su partizioni montate e' rischioso 
e NON va fatto?
10X!
-- 
void 
Stefano_Jodi...@tiscalinet.it
()
{  /* registered Linux user # 249693  kernel 2.4.20   */
printf ("L i n u x  a d d i c t i o n  c o u l d  k i l l  y o u "); }

 e NON va fatto?
In particolare, sapevo che nelle ultime versioni (mi pare da 2.4.16 in avanti) 
fosse altamente sconsigliato usare tune2fs -j su partizioni montate;
in generale, sapevo che e` sconsigliabile usare tune2fs su partizioni montate
(o al limite in ro), e sono sempre stato prudente in merito...
(un'altro buon motivo per separare le partizioni da / :)
-- 
Ikitt

 giorno sono passato dal kernel 2.4.18 al 2.4.20. 
Leva quel kernel! E rimetti il .18. Se usi ext3 con l'opzione data=journal 
(che non e' comunissima per fortuna) potresti tritarti il filesystem. Questa 
mania pericolosissima di usare le tarball dei kernel appena usciti...
Tenetevi quelli delle distribuzioni, che almeno sono testati: moltissimo 
quelli debian, molto quelli redhat e suse e almeno un po' quelli mandrake.
-- 
Enrico Bodo  -   Postdoctoral Research Fellow      
University of Rome "La Sapienza" 
Department of Chemistry         

 (che non e' comunissima per fortuna) potresti tritarti il filesystem.
Dove si vede se e' usata l'opzione data=journal ?
-- 
ciao            |visita
                 |
http://www.sifor.it
gelty           |
http://www.sifor.com
-------------------------------------
Elimina toglimi. per le risposte
E' esplicitamente vietato usare l'indirizzo e-mail di questo messaggio
per fini diversi dalla risposta al messaggio stesso (Art. 10 DL. 171/98).

 Dove si vede se e' usata l'opzione data=journal ?
Se non lo sai dove, allora non l'hai usata.
Il default è `data = ordered'.
Ciao,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)           [ 
http://www.radiance.ods.org/~zefram
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

 mania pericolosissima di usare le tarball dei kernel appena usciti...
Potresti, ci sono stati due casi (a quanto ricordo) dal 2.4.19rc5.


 Potresti, ci sono stati due casi (a quanto ricordo) dal 2.4.19rc5.
Andrew Morton ha inviato la patch che corregge il bug sulle mailing list
linux-kernel ed ext3-users alle cinque di questa mattina (ora italiana).
Ciao,
 Emmanuele.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Per informazioni si veda 
http://www.gnupg.org
iD8DBQE98LzEjszbj6QyD/QRAoDcAJ91WektjTFgGNOYyU5pzUDWLmQP2ACgpUSq
ht7C1ErP/dp6tMCSYii9l3Q=
=3C1O
-----END PGP SIGNATURE-----


 usciti...
mi risulta che riguardi solo la modalita' journal. io uso e intendo usare 
quella ordered, e presto applichero' la patch per quel bug. cmq vivevo 
felice gia' col 2.4.18 e non mi ci vuole niente a ripristinare quell' 
immagine come default.
ad ogni modo insisto nell' idea di voler convertire la mia partizione root 
/ , hda7, ad ext3. 
sarebbe una buona idea usare il liveCD della suse 7.3, che contiene gli 
E2fsprogs (e il kernel 2.4.10, mi pare) per convertire la mia root 
SMONTATA, modificare fstab e riavviare? ebbene si' , tutto il sistema 
(/boot, /bin, /usr /dev...) e' installato su un' unica partizione root di 
ca 2 Gb risiedente su hda7, la /home su hda9, e una partizione riservata ai 
dati in un disco (hdb1) aggiunto di recente per cose ingombranti come le 
immagini dei dischi virtuali di vmware , ma si tratta di una configurazione 
risalente a un paio di anni fa quando nulla sapevo di linux. 
Mi pare di aver capito che al limite , se qualcosa va storto, la partizione 
dovrebbe essere montata come ext2, oppure (probabile...) tralascio qualcosa 
di importante? 
Ovviamente la mia priorità è di non perdere dati e configurazioni, sennò 
che me ne fregherebbe di ext3? ;-)
void 
Stefano_Jodi...@tiscalinet.it
()
{  /* registered Linux user # 249693  kernel 2.4.18   */


 Dove si vede se e' usata l'opzione data=journal ?
Se non l'hai impostata tu, allora hai data=ordered. Pero' quel kernel 
evidentemente non e' stato testato abbastanza.


 di importante? 
Non saprei, forse c'e' un'opzione da passare al kernel. Oppure lo fa di suo.
-- 
Enrico Bodo  -   Postdoc Fellow       


 Potresti, ci sono stati due casi (a quanto ricordo) dal 2.4.19rc5.
Ma lui da quanto ho capito voleva convertire a mano le partizioni, mi 
sembrava possibile che gli venisse in mente di usare l'opzione incriminata, 
magari per fare un test, e si disintegrasse i dati.
Poi non ho capito. Tu useresti un kernel del genere? A me sembra che sia
stato testato un po' poco (come minimo). Ormai i kernel che buttano fuori
sono poco piu' di una pre[1]. Io sono sempre stato alla larga dai kernel
dell'ultima ora che infatti si rivelano spesso problematici. Sono sempre
piu' convinto che possano essere usati solo da chi fa i test.
[1] Non e' la prima volta che una release ufficiale rischia di sputtanarti 
il filesystem; un anno fa e' successa una cosa analoga anche se piu' 
pericolosa.
-- 
Enrico Bodo  -   Postdoc Fellow       


 pericolosa.
Allora, il 2.4 (2.4.11 per la precisione, e poi 2.4.15) era ancora
abbastanza giovane. Adesso si sta rifinendo il tutto, in attesa del 2.6,
verso giugno 2003)... Poi i casini saltano sempre fuori, in fondo anche
i programmatori sono esseri umani.


 i programmatori sono esseri umani.
Mica me la prendo con i programmatori. Ci mancherebbe. Secondo me se si
necessita di un ambiente stabile e' meglio aspettare sempre un po' prima di
installare l'ultimissimo kernel. Mi sento piu' sicuro quando un kernel passa 
anche per le mani dei tester delle distribuzioni, anche se poi il baco puo' 
sempre scappare fuori.


 sbaglio di brutto ed e' stata solo sfiga...
In parte è stata una questione di come è realizzato il VFS: secondo
Andrew Morton è troppo `ext2 centric' nelle operazioni di sync.
Non appena è stata tentata l'ottimizzazione di questa parte del codice,
comprensibile a questo punto dello sviluppo del tree, è saltato fuori
un difetto del VFS, che dovrebbe essere corretto nel 2.5.x.
Il fix proposto permette di mettere ext3 a posto nel 2.4.x, ma il
VFS sarà corretto nel kernel sperimentale (come è giusto, in fondo,
che sia).


 direi pochino. Io rimarrei su un kernel da distribuzione.
io no.
cmq neanche il 2.4.18 che usavo prima senza il minimo problema (dopo una 
lunga configurazione) era "da distribuzione", veniva fuori da un tarball 
anche lui.  quello originale della distro  era il 2.4.9 (mdk, ovvio)
ma che cosa e' tutto questo feticismo della distribuzione? nostalgia di 
windows?  capisco che installare un kernel appena sortito e' 
(moderatamente) rischioso, daccordo, ma non vedo perche' non approfittare 
per imparare qualcosa. 
ad ogni modo per prudenza oggi ho fatto il boot col 2.4.18 ;-)
-- 


 per imparare qualcosa. 
3) Non insegna praticamente nulla ad un nuovo utente. Ad uno che non sa cosa
vuol dire il comando 'make' cosa potra mai far imparare di linux il
ricompilare un kenel? Prima di ricompilare il kernel ci sono cose molto piu'
divertenti e utili da imparare. 
4) Il continuo e martellante (adesso un po' meno) ricorso al cosiglio:  
"ricompila il kernel" e' sbagliato nel 90% dei casi, fuorviante e genera una
enorme mole di traffico evitabile del tipo:
"Mi sono ricompilato il kenel adesso non parte piu' linux"
"Devi ricompilare il kernel. Cosa sono i moduli?"
"Ho ricompilato il kernel e non stampo piu'"
.....
.....
5) Il kernel va ricompilato solo quando se ne ha una reale necessita'.
6) Il punto di forza di linux *non e'* la possibilita' di ricompilare il 
kernel. Linux non e' superiore a windows perche' si puo' ricompilare il 
kernel, ma per una infinita' di altri motivi.


 5) Il kernel va ricompilato solo quando se ne ha una reale necessita'.
su questo sono daccordo. quando sono passato al 2.4.18 l'ho fatto perche' 
volevo il supporto ext3 piu' altre cosette, e piu' recentemente ho provato 
il 2.4.20 perche' dovevo aggiungere i moduli per una scheda di rete ed il 
supporto per il filesystem SMB, e trovandomi facendo non ho ritenuto tanto 
rischioso provare un kernel un po' giovane. 
il 2.4.20 da me non da(va) nessun problema, non metto in dubbio che il bug 
del data=journal esista e sia pericoloso ma, come ho gia' detto, per ora si 
torna al 2.4.18.
ho convertito e montato / come ext3 e tutto e' andato liscio. ringrazio 
tutti per la pazienza mostrata.
 quanto alla sparata della nostalgia di windows... ň! e scherzavo! :-) 
