Newsgroup: it.comp.os.linux.sys
Titolo: Salta la corrente e perdo dati!

Purtroppo a causa della mancanza di corrente di questa notte ho perso dei
dati dal server linux.
E' ripartito quasi tutto, dopo che al riavvio ho avviato il controllo delle
partizioni. Poi da KDE lancio konqueror e mi dice che manca libkhtml.
Entro in usr/lib e vedo che un sacco di collegamenti hanno il "?" e mancano
dei file.
Riporistino libkhtml copiandolo da un PC linux della rete.
Ora mi chiedo... com'è possibile aver perso dei dati per una mancanza di
correte? Con partizione ext3 con jounrnal ???
E non è la prima volta!!!! Non per dire... ma con NTFS su winserver2003 non
mi è MAI successo.
la cartella lost+found è vuota!
Consiglio?
Grazie...
Daniele


Backup. Assicurati che l'HD sia ancora fisicamente integro. In bocca al
lupo.
Alessandro.

 Con partizione ext3 con jounrnal ???
Non e' la prima volta che lo sento. Il fs journaled ti assicura la
coerenza dei dati, non il non perdere dei file se il fs si danneggia.
E' a questo che servono i backup.
Davide

 Consiglio?
Approfondire le tematiche della manutenzione ordinaria e straordinaria
di un server (qualunque sistema operativo).
-- 
                         Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
One item could not be deleted because it was missing.

a parte usare ext3 o un filesystem journaled, io mi avvalgo di un 
piccolo ups con cavo seriale in modo che in caso di baclkout, dopo 120 
secondi e comunque prima che quest'ultimo esaurisca la sua carica, il 
server faccia da solo uno shutdown. al massimo ci vuole l'omino che fa 
ripartire il server se io non ci sono (tasto di accensione basta) ma in 
questo modo non perdo mai i dati. Anche a casa uso un piccolo ups della 
riello, sempre con cavo seriale, lo ho pagato men odi 100 euro, secondo 
me ne vale la pena.
-- 
Davide Corrado
to send mail, remove "no_spam_" from the address

 
Questo è logico... ma mi lascia molto perplesso il fatto che dopo 2
spegnimenti del genere per 2 volte perdo dati. Veramente triste!
Ciao, grazie
Daniele

 
Eh si... dove lavoro (in hp, assistenza netserver) queste cose non le
approfondiscono !!
Io non sto parlando di questo... sto parlando del fatto che dopo 2
spegnimenti improvvisi per 2 volte ho perso dati..
La cosa è racapricciante!
Ciao...
Daniele

 La cosa è racapricciante!
Disco farlocco.
-- 
                         Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
All science is either physics or stamp collecting.

 spegnimenti del genere per 2 volte perdo dati. Veramente triste!
Non è che quel server e quei dischi sono un pò troppo sottodimensionati?
Se fosse un pò più veloce magari ce la farebbe a flushare i dati come si
deve.
--------------------------------
Inviato via 
http://usenet.libero.it

 fortemente rivedere il concetto di "approfondimento".
Eppero' i fs journaled dovrebbero garantire che una transazione "committed"
sia "committed" per davvero: con NTFS, se il log riporta che un file e' su
disco, puoi star tranquillo che quel file si trova su disco (mi e' capitato
una sola volta di trovarmi un problema di perdita dati veramente grave su un
NTFS - ok, quell'unica volta sono stato costretto a buttar via NT e mettere
un 2000, ma e' stato un caso unico in otto anni), mentre ho letto, su questo
stesso NG, che con fs journaled per linux (mi pare reiser, ma non sono
sicuro) puo' capitare di trovarsi dati non coerenti con i metadati a cui
fanno riferimento (ovvero, il file c'e', e' della dimensione giusta, pero' i
dati all'interno sono random - probabilmente i metadati sono stati scritti e
dichiarati coerenti prima che venissero salvati i dati, quindi i settori
contengono "roba vecchia").
E' perfettamente accettabile che un file aperto venga ritrovato in uno stato
precedente (se i metadati non risultano committed, fanno fede quelli
vecchi), e quindi che scompaia se era un file creato di recente (o mai
salvato su disco dal kernel), non lo e' che possa trovarsi in uno stato
*indefinito*.
Se questo accade vuol dire che le transazioni non sono atomiche, e
soprattutto che il file system non e' in grado di garantire la coerenza tra
i dati e i metadati; non pretendo che i dati ci siano, non e' questo lo
scopo dei fs journaled, solo che i dati e i metadati che li descrivono
stiano parlando della stessa cosa.
Ciaotutti,
*

 che li descrivono stiano parlando della stessa cosa.
Quando questo e` successo, verosimilmente, e` perche` la macchina non
regge l'overhead di "journalare" sia dati che metadati. Ma il problema
non e` "una macchina piu` grossa". Il problema e` far fare, ad ognuno,
il proprio compito.
-- 
                         Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
Real programmers can write assembly code in any language.

 il proprio compito.
Uhm... Non ti seguo.
Il problema in questo caso e' che i metadati sono stati modificati, e
dichiarati coerenti (tra loro) prima che i dati a cui essi facevano
riferimento fossero a loro volta effettivamente stati salvati.
Ora, che i metadati siano coerenti tra loro e' sicuramente fondamentale, ma
altrettanto importante e' che se la copertina del libro titola "i promessi
sposi", e l'indice e' quello dei promessi sposi, il contenuto *non* sia la
divina commedia...
A questo punto, per garantire cio', a chi ci si deve rivolgere?
Un fs journaled garantisce che copertina e indice siano coerenti, ma chi
garantisce che la copertina venga apposta sul libro solo dopo che le pagine
sono state stampate?
Ciaotutti,
*

Scusate se mi intrometto e se magari vado fuori tema, ma questa cosa mi
rode da parecchio tempo e ultimamente anche di piu'.
Da noi abbiamo installato per anni SCO Unix.
Confrontandolo adesso con linux che stiamo usando da qualche tempo noto
che l'unica cosa che il linux ha da invidiare allo unix di SCO e' la 
solidita' del filesystem.
Cosa diamine avra' il fs di SCO che i vari ext2, ext3, Reiser non hanno ?
-- 
Stefano L.

 sono state stampate?
Relativamente al solo ext3 (reiser non lo uso, non mi piace), funziona
esattamente cosi`, a meno che *tu* non abiliti l'opzione "salva anche i
dati". Infatti, nella man page di mount, alla sezione ext3 si legge:
       data=journal / data=ordered / data=writeback
              Specifies  the  journalling  mode  for  file  data.
              Metadata is always journaled.
              journal
                     All data is committed into the journal prior
                     to  being written into the main file system.
              ordered
                     This is  the  default  mode.   All  data  is
                     forced  directly out to the main file system
                     prior to its metadata being committed to the
                     journal.
              writeback
                     Data ordering is not preserved - data may be
                     written into the main file system after  its
                     metadata  has been committed to the journal.
                     This is rumoured to be the  highest-through­
                     put  option.   It  guarantees  internal file
                     system integrity, however it can  allow  old
                     data  to  appear  in files after a crash and
                     journal recovery.
Come vedi, l'opzione di default "ordered", e` quella che ha senso (prima
il romanzo, poi la copertina). AFAIR, quelli che hanno avuto i problemi
di cui si citava in precedenza, usavano altre opzioni (e mi riallaccio
al discorso di prima).
Su reiser bisognerebbe fare un discorso a parte, perche` a mio *gusto*,
e` "flaw by design", ma non mi interessa la filesystem-war (per altro,
diverse volte gia` passata).
-- 
                         Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
There's no place like /home.

 Cosa diamine avra' il fs di SCO che i vari ext2, ext3, Reiser non hanno ?
Nulla. Si schiantava anche lui ne piu` ne meno di ext2 (e piu` di
ext3/reiser/xfs...). Quello che e` vero, e` che:
- in anni passati l'hardware era qualitativamente di miglior fattura ma
  a prezzi sensibilmente maggiori. La tecnologia dei componenti e`
  sensibilmente peggiorata, a fronte pero` di un minor costo.
Questo produce un falso senso di protezione: vedo sedicenti server con
mobo e dischi di qualita` "entry level". Questi valgono tanto quanto
costano. Le tecnologie tipo smart sono degli accrocchi. C'e` modo di
fare un "buon" server, e come in anni passati, costa.
Oggi lo fai con array di dischi, mirroring, raid, ecc. In passato lo
facevi con dischi singoli, ma che qualitativamente costavano di piu` e
valevano molto di piu`.
Ovviamente questo discorso e` estendibile un po` a tutto l'hardware.
Questo e` il fattore principale.
Il resto e` casistica occasionale, che a parte per chi la subisce, e`
purtroppo poco significativa. Ho diversi server in produzione su ext2 da
anni, mai perso un dato (e mi sto toccando in questo momento, e dopo
vado a controllare i backup :)).
-- 
                         Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------


 i dati". Infatti, nella man page di mount, alla sezione ext3 si legge:
[SNIP]
Quindi finche' il kernel non scrive i dati su disco, i metadati rimangono
sospesi...
Beh, ha senso, anche se mi pare di aver letto di strani comportamenti (file
spariti) con ext3, su reboot cattivi dopo un flush manuale. Pero' non sono
sicuro al 100%.
Ciaotutti,
*

 sicuro al 100%.
Non mi risulta per ext3. Mi risulta una cosa del genere, su reiser,
nella sua prima incarnazione. Ma come ti dico, stiamo lambendo la
fs-war.
-- 
                         Maurizio - Tannoiser - Lemmo
                 Founder Member of ERLUG 
http://erlug.linux.it
-------------------------------------------------------------------------------
To iterate is human; to recurse, is divine.

 riferimento fossero a loro volta effettivamente stati salvati.
E' esattamente ciň che fa ext3 di default (data=ordered).
La perdita di coerenza del fs non č possibile a meno di bug gravi.
I dati sono scritti prima dei metadati che li puntano, quindi sono
impossibili anche corruzioni di file che contengono pezzi di altri file
rimossi prima.
L'unico problema che rimane č che al reboot i dati siano aggiornati
all'ultimo upgrade, ma bisogna ricordarsi che tra le applicazioni
e il disco c'č una cache e se si vuole essere sicuri che i propri
dati siano al sicuro č necessario dirlo esplicitamente con fsync()
e compagnia.
In tutti gli altri casi o non si tratta di corruzione dati oppure
c'č qualche bug serio in ext3, o nel driver del disco. O problemi hw.
-- 
Lorenzo

 ext3/reiser/xfs...). Quello che e` vero, e` che:
Non sono mica tanto d'accordo.
Prima di OpenServer 5.0.0 si schiantava eccome.
Ma dal 5.0.0 non ne ho mai piu' visto uno rovinarsi su un numero di 
installazioni a 3 cifre.
Puoi staccargli la spina mentre lavorano in 20 e non fa' una piega.
Dici che sono stato fortunato ?
Sul fatto che poi ups e backup siano di rigore in ogni caso, sono
pienamente d'accordo.
-- 
Stefano L.