Newsgroup: it.comp.os.linux.iniziare
Titolo: [niubbo] Journaled Filesystem

Salve a tutti
sto smanettando un po' con linux (in particolare con la Slackware 10), 
dato che sono intenzionato seriamente ad abbandonare winzozz (almeno per 
le cose serie lol).
A proposito dei diversi fs, ho notato cmq una cosa che mi ha lasciato 
piuttosto perplesso.
Premesso che preferisco sempre l'affidabilità alla velocità, è mai 
possibile che, all'atto pratico, ReiserFS e Ext3 (quest'ultimo impostato 
in modalità data=journaled), siano VERAMENTE inaffidabili al confronto 
di NTFS? o.O
Ho riscontrato questo: 
la prima volta ho installato linux con ReiserFs nella partizione di 
root. Tutto bene finché ad un certo punto è andata via la luce (capita 
lol). Al riavvio, mi ha fatto il check della partizione, rilevando una 
serie di errori e correggendoli, con il risultato di sputtanarmi alcuni 
file di sistema (quelli del desktop grafico in particolare).
in seguito ho configurato una partizione per la directory /home con Fs 
Ext3 in modalità data=journaled (volevo proprio andare sul sicuro). Ad 
un certo punto è di nuovo andata via la luce (e vabbè.. che ce volete fa 
:P), proprio mentre stavo copiando un file in /home. Non mi aspettavo 
certo di recuperarlo al riavvio, ma che addirittura si fosse sputtanato 
il superblock col risultato di non poter neanche fare il mount della 
partizione, no eh.. :P
Ora.. sono ancora ignorante in materia ma:
nel primo caso non credo ci sia rimedio, visto che cmq ReiserFS dovrebbe 
essere moolto più veloce ma cmq meno sicuro di Ext3 (data=journaled), 
correggetemi se sbaglio.
Nel secondo caso, è mai possibile che nell'eventualità di un problema 
banale che causa uno spegnimento improvviso, si debba perdere tutto?
Winzozz sarà pure winzozz, ma NTFS l'ho sempre considerato blindatissimo 
(MAI perso nulla). Sono rimasto un po' male insomma (ma magari sto 
facendo qualcosa di sbagliato).
illuminatemi plz :P

 illuminatemi plz :P


http://csvtosql.sourceforge.net/

 sistema installato/configurato?
durante il normale utilizzo.

 un buon elettricista ? :) :)
In anni di NTFS non ne ho mai sentito il bisogno lol :PPPP

 durante il normale utilizzo.
E' molto strano. Prova magari a controllare con HDPARM ilparametri del 
tuo disco fisso e raffrontali con le specifiche fornite dal costruttore. 
Se ci sono delle discordanze tra i valori (C/H/S ecc.) può darsi che 
Linux non sia nelle condizioni ottimali per recuperare i dati in seguito 
a black out.
questo è quello che mi è venuto in mente. Se mi dai qualche altra 
informazione, magari posso aiutarti meglio a capire.  Marca Hd, versione 
BIOS della macchina, scheda madre ecc.
Ciao

 BIOS della macchina, scheda madre ecc.
E' un Western Digital (U-ATA66) da 18Gb su controller Promise (PDC 20265 
se ricordo bene). La MB è una ASUS A7V con l'ultima versione di bios 
installata. Attualmente è partizionato così (valori arrotondati, vado a 
memoria :P)
hdh1 ext3 - 6 Gb
--- extended
hdh5 swap - 512Mb
hdh6 ext3 - 3,8Gb
hdh7 ext3 - 3,8Gb
hdh8 ext3 - 3,8Gb
---
nell'ultimo caso era andata a puttane la partizione hdh8 (/home).
grazie

 grazie
Ciao

 Inoltre fammi sapere se hai fatto quella verifica con hdparm.
appena posso la faccio :)
grazie

> secondo te qual'è?
rotfl :)



Ok, non l'avevo visto, ma invece di fare del sarcasmo inutile cerca di 
aiutare qiesto disgraziato a risolvere il problema.
Dico bene?

 dovuti accorgimenti non sia in grado di garantire tale integrità. o.O
I casi sono due:
1- imbrogli
2- imbroglia win ntfs.
3- In omaggio, tre per due: hai una fortuna sfacciata, e questo a
prescindere dal sistema operativo.
:-)
Seriamente, analizziamo il problema.
La perdita di dati da black out si verifica per mancata scrittura da 
parte della cache verso i dischi.
Tale cache e' presente sia in ntfs, sia in ext2, ext3, altri journaled.
La perdita di dati e' possibile in tutte queste configurazioni.
La cosa che puo' far preferire un journaled e' solo il fatto che il
file system, anche se perde i dati, resta in uno stato consistente,
cosa che con ext2 non capitava sempre, a volte si perdevano belle
fette di file system.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 fette di file system.
Mio Dio, vuoi vedere che ho sempre avuto culo? :P
Cmq a parte tutto, prendiamo il caso che mi ha lasciato un po' più 
perplesso:
Ext3 con data=journaled blah blah blah va in palla e al riavvio mi dice 
che non può fare il mount (wrong fs type, bad option, bad superblock, 
etc. etc.). Ora te dimmi se soltanto copiando UN file, devi perdere una 
partizione.. no davvero, questo non è degno neanche di Bill Gates rofl.
Cercando su google ho scoperto che c'è un modo per recuperare il 
superblock a mano (se poi è questo il problema), andando a specificare 
il settore di backup nella partizione (O_O ma non potevano farlo 
automatico sto procedimento?).
Qualcosa tipo e2fsck -b 8193 <device>
..il numerello 8193 credo cambi a seconda dei casi... mhh
A saperlo prima.. avrei tentato, fortuna che erano solo prove.

 sto smanettando un po' con linux (in particolare con la Slackware 10),
Come hanno risposto altri, anch'io ho subito più volte degli spegnimenti
improvvisi del sistema, ma non ho mai avuto problemi.
Ma posso essere stato fortunato.
L'unica cosa che mi viene in mente... non è per caso che usi il kernel
2.6.7? Non so se possa influire, ma non si sa mai... Magari un kernel meno
giovane è più affidabile.
BlueSky
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 partizione.. no davvero, questo non è degno neanche di Bill Gates rofl.
ecco questo e' _molto_ strano.
AFAIK ogni volta che crei un filesystem ext3 vengono create _diverse_
copie del superblocco in modo da poterle poi recuperare in casi di
scioppamento.... soc! ti son scioppati tutti in un colpo? hai voja la
jattura! :D
-- 
Le uniche conquiste che non lasciano nell'animo amarezza sono quelle che
si vincono contro l'ignoranza. [Napoleone]

 illuminatemi plz :P
Si basa tutto su un tuo assunto sbagliato: il compito di un filesystem
journaled non è garantire l'integrità dei tuoi dati; quella la ottieni
solo con un RAID, un UPS e l'aiuto del buon Dio.
Un JFS garantisce solo l'integrità del filesystem. I due giga di porno
o i cinque di MP3 potrebbero diventare encodings delle libc, ma il tuo
filesystem sarà sempre in uno stato consistente.
Ciao,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)                 [ 
http://www.emmanuelebassi.net
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

 automatico sto procedimento?).
No.
Tu sei root, e come tale, SAI cosa ti conviene fare per recuperare tutto
il possibile da una situazione di guasto, perche' questo e' un guasto.
IL riprendere un superblock vecchio ma funzionante puo' essere una delle
soluzioni, ma potresti voler tentare altre vie, piu' ardite, ma con la
possibilita' di perdere meno dati.


A saperlo prima.. avrei tentato, fortuna che erano solo prove.
Quello che ti consiglio di fare e' di fare il fsck specificando la
dimensione dei blocchi:
-B 4096
Il tutto dovrebbe essere eseguito, per precauzione, in sola lettura,
quindi usando l'opzione -n
Se i superblocchi di backup vengono trovati, allora togli l'opzione
-n.
In via preventiva invece potresti effettuare qualcosa di piu'
interessante.
Sappiamo che la system cache (o FS cache, o buffer cache) viene usata
per ottimizzare le prestazioni. Di contro aumenta l'esposizione a
inconsistenza di dati e meta-dati (superblocchi, inode, directory, et
al.), in quanto ritarda l'effettiva scrittura dei dati sul disco.
Premesso che ogni file system, come detto prima pure NTFS, ha bisogno
del suo parametro di frequenza dei flush, per ottimizzare le
prestazioni nel caso medio, e tale parametro e' deciso dal produttore,
e' tuttavia vero che ogni utente ha le sue esigenze.
Come si legge dal man di bdflush(8), esso fa partire un kernel thread
che si occupa di eseguire il flush della cache con una certa
regolarita' secondo certi criteri.
In particolare nei criteri ci sono due parametri interessanti:
- "data age": e' il massimo tempo di permanenza che un buffer dirty
[3] contenente dati propri puo' attendere prima di essere flushato
- "metadata age": e' il massimo tempo di permanenza che un buffer
dirty contenente metadati (superblocco, inode, freespace bitmap,...)
puo' attendere prima di essere flushato.
I valori di default per questo due parametri sono 30 e 5 sec.
rispettivamente.
Praticamente significa che quando tu scrivi dei dati questi possono
essere flushati su disco dopo al massimo 30 sec. (possono essere
flushati prima).
Riducendo i due parametri avresti in effetti un disco piu' aggiornato
rispetto alle tue operazioni, e quindi meno soggetto a perdite di dati
causate da imprevisti, ma le prestazioni potrebbero calare.
Personalmente penso che toccare il "data age" e' quasi inutile: in 30
sec. non fai granche' di diverso da quello che c'e' gia' su disco;
mentre toccare il "metadata age" in effetti potrebbe ridurre circa
linearmente la probabilita' di inconsistenza del file system in casi
di blocchi imprevisti, pero' quando il disco e' sotto carico un
metadata age alto e' una manna per le prestazioni. Ripeto ancora che
questa e' un'opinione.
Riguardo alla modifica dei due parametri bisogna trovare tra i file di
configurazione la riga che lancia il comando di bdflush: /sbin/update.
Io l'ho trovato in /etc/inittab, ma e' bene guardare in:
/etc/rc.local
/etc/rcS
/etc/rc
/etc/rc.boot
/etc/rc.sysinit
e negli script puntati dai link in:
/etc/rcS.d
/etc/rc3.d
/etc/rc2.d
Bisogna poi aggiungere le opzioni -5 o -6 con argomenti, es.:
/sbin/update -5 10 -6 4
[1]: Lo scaricamento dei dati nella buffer cache verso i dischi.
Trascuriamo completamente per semplicita' il fatto che i dati vengono
a loro volta cachati dal firmware del disco, per cui un dato flushato
non e' un dato memorizzato in memoria di massa.
[2]: facendo la scansione di una parte del disco potremmo avere una
buona probabilita' di azzeccare la dimensione. Magari un'utility del
genere esiste gia', e se non esiste bisognerebbe inventarla.
[3]: un dato in memoria e' dirty se il suo back-store non contiene lo
stesso dato. Es. un buffer in FS cache e' dirty se contiene un file
che e' diverso da quello associato contenuto nel FS.
Solitamente un buffer dirty significa che l'utente ha modificato un
file ma non e' stato scritto su disco.
-- 
Linux Registered User #181013
[Exokernels] Although one approach to eliminating bloated, buggy,
unreliable operating systems is to make them smaller, a more radical
one is to eliminate the operating system altogether.

 illuminatemi plz :P
occhio a usarla con parsimonia la luce... salta la corrente ;-))
Ciao,
Giuseppe
-- 
"Guarda, una scimmia a tre teste!"

[cut]
Sei stato veramente esaustivo.
Ti ringrazio infinitamente!

 occhio a usarla con parsimonia la luce... salta la corrente ;-))
rofl

 I due giga di porno potrebbero diventare encodings delle libc
lol. Questo si che è terribile! :P

 giovane è più affidabile.
nono, uso quello di default nella slack 10, il 2.4