Newsgroup: it.comp.os.linux.sys
Titolo: NON CI POSSO CREDERE!!!

oppure ho sbagliato qualcosa...
Slackware 8.1 con XFS (kernel 2.4.18 patchato con XFS e ricompilato)
apro PICO per creare un nuovo file di nome PROVA
scrivo "PRIMO RIGO"
salvo e chiudo
riapro e scrivo "SECONDO RIGO"
salvo
scrivo "TERZO RIGO"
resetto il pc (cioč tolgo la corrente simulando il fermo a seguito di un
blackout)
al riavvio riapro il file PROVA che ha il seguente contenuto
PRIMO RIGO
UUUUUUUUUUUUUU
faccio la stessa cosa con VI
e quello che ottengo č un file BINARIO illeggibile
credo sia un  problema di XFS
ma quale (tuning, altro)?
grazie per l'attenzione

 ma quale (tuning, altro)?
Tragico.. anche io uso XFS.. appena so di poter spegnere la macchina un
attimo faccio la prova.. 
-- 
-   Federico Sideralis Programs 
www.sideralis.net
   -
-   Server Fastweb IRC 
irc.sideralis.fastland.org
   -
- Renault Espace 
www.sideralis.net/espace/index.htm
 -
-   Linux Gentoo 1.4 2.4.19-xfs-r1 [i686/604MHz]    -



E perchč un problema? XFS tiene salvi i metadati, mica i dati veri e
propri: lo fa solo ext3 con un parametro (rallenta un po' troppo!). La
funzione degli FS journaled sta nel salvare la consistenza logica del
disco.
-- 
Roberto Tagliaferri<-> r.tagliaferri@(forse)
tosnet.it
	Sentito da una programmatrice:
	"Ma vi capita mai nella vita reale, tipo mentre
	rifate il letto di dire 'Ho sbagliato, pigio ctrl-Z'?"

 disco.
Mmm... Si', ma questo ha senso solo finche' tu salvi, risalvi, trisalvi e
perdi gli ultimi due save: se il file contiene solo un dato binario
illeggibile significa che la consistency e' andata a fasi benedire:
l'allocazione di spazio su disco dovrebbe essere coerente con i dati salvati -
a meno che vi non allochi una porzione di disco pari a un'unita' di
allocazione *prima* di salvare qualunque dato, in quel caso il fs sarebbe
perfettamente coerente, visto che avrebbe comunque mantenuto uno stato del
disco coerente con una situazione stabile...
Ciaotutti,
*

 illeggibile significa che la consistency e' andata a fasi benedire:
sono d'accordo
e infatti avevo scelto XFS proprio per questo
ora non so che pesci pigliare

fammi sapere
"Federico" <fede...@sideralis.matrix> ha scritto nel messaggio
news:pan.2002.10.18.12....@sideralis.matrix...


 scribbled:

Pero' hai rimosso l'eccezione: se (e solo se) vi alloca prima lo spazio con
qualche chiamata di sistema e solo dopo salva il file... Beh, allora XFS ha
fatto il suo lavoro, salvando uno stato comunque stabile.
Ciaotutti,
*

 a meno che vi non allochi una porzione di disco pari a un'unita' di
Il FS alloca il blocco, ma non e` detto lo
scriva, e` sempre asincrono.
Infine, il FS journaled _non_ fa i miracoli,
specie se si incrociano i requisiti di sicurezza
e di prestazioni.
bye,
-- 
piergiorgio


Teoricamente richiedendo un flush non dovrei poter garantire la coerenza del
dato?
Pagando in prestazioni, si intende...
Ciaotutti,
*

 Pagando in prestazioni, si intende...
Teoricamente si, ma nel test fatto non c'era
nessun "sync", mi pare.
Il FSJ non e` un FS sincrono di suo.
Semplicemente mette piu` "sforzo" nel cercare di
mantenere la coerenza dei metadati.
Tra l'altro neanche "sync" garantisce al 100% la
scrittura dei dati, ma e` sempre meglio di niente.
Nota che se perdi un blocco del file, potresti
comunque salvare qualcosa, se perdi un blocco di
"metadati", potresti perdere tutto il file.
bye,
-- 
piergiorgio

 scriva, e` sempre asincrono.
insomma io vorrei usare XFS anche per il supporto ACL (SAMBA) c'è una
maniera per evitare il probelma riscontrato (forzando la modalità
sincrona anche a scapito delle prestazioni?)

 scrittura dei dati, ma e` sempre meglio di niente.
fatta la stessa prova, ma dando un sync prima di togliere
la corrente
funziona! (come reiserfs, solo che con questo fs non devo manualmente
dare sync!)
c'è un modo per far comportare XFS com reiserfs?

 c'è un modo per far comportare XFS com reiserfs?
Mah, un trucco "sporco" e` avere un demone tipo:
while :
do
  sync
  sleep 1
done
che da un "sync" al secondo... :-)
Volendo si potrebbe fare piu` spesso
(ogni mezzo secondo?).
Non e` pero` il massimo... (Ma ha salvato
parecchi lavori, in passato).
bye,
-- 
piergiorgio

 sincrona anche a scapito delle prestazioni?)
Non saprei, immagino di si.
bye,
-- 
piergiorgio


A cosa ti riferisci? Al caso di controller con cache in scrittura abilitata?
Disco che "accidentalmente" scrive i dati sbagliati?
O ci sono anche questioni di... software?
Alessandro.

 O ci sono anche questioni di... software?
Normalmente i dati non vengono immediatamente
trasferiti sul disco, bensi` il SO li bufferizza
in RAM e poi, con calma, li scrive su disco.
Se succede qualcosa tra i due momenti, rischi di
perdere informazioni.
Altresi` e` possibile scrivere direttamente i
dati sul disco, senza passaggio in memoria.
In questo caso la scrittura avviene immediatamente,
ma il programma deve aspettare che sia finita,
quindi le prestazioni calano. Notevolmente.
Tra l'altro, bufferizzare in RAM consente di
scrivere gruppi di blocchi in maniera contigua,
evitando cosi` la frammentazione del disco...
bye,
-- 
piergiorgio

 *
 
No, la lunghezza del file in blocchi è la stessa e la consistenza viene
mantenuta (imho), infatti non hai nessun problema ad accedere al file ma
hai problemi sul contenuto


 quindi le prestazioni calano. Notevolmente.
Tra l'altro, in caso di traffico elevato,
potrebbe anche rallentare tutto il sistema,
in modo tale da rendere ancora piu` pericoloso
un possibile crash.
bye,
-- 
  Piergiorgio Sartor


Si, ma la sync non forza il flush di questi buffer su disco?
Perche' al termine della chiamata sync non dovrei essere ancora sicuro che i
miei dati siano salvati su disco?
Alessandro.

 miei dati siano salvati su disco?
Credo perche` il sistema e` sempre asincrono,
durante il "sync" altri eventi possono accadere.
In generale e` abbastanza sicuro, nel senso che
una volta dato il "sync" i dati attuali sono su
disco, senza problemi.
bye,
-- 
  Piergiorgio Sartor



Ci può essere sempre la cache del controller o dell'hd


 al file ma hai problemi sul contenuto
E questo si differenzia dalle FAT per...? OK, sulle FAT devo fare uno scandisk
per ottenere lo stesso risultato, a rimane il fatto che se ho un file aperto e
crasha tutto dopo il riavvio (e il lungo scandisk) mi trovo dei file
incoerenti; con un FS journaled io vorrei trovarmidei file coerenti con almeno
uno degli stati precedenti (ovvero, se mi trovo il dato di ieri va bene, se
non trovo piu' dati intelleggibili va male).
Ciaotutti,
*

 *
 
Mi sa che lo fa ext3 (che """"giornala"""" anche i dati veri e propri)
