Newsgroup: it.comp.os.linux.sys
Titolo: Recupero file in lost+found

Ciao,
ho una macchina con Hard Disk scsi ext3 che dopo un crash ed un fsck,
ha perso una dir. di circa 3 Giga di immagini, che sono finite
in lost+found:
-rw-r--r--    1 root     root         2257 dic  1  2001 #1769993
-rw-r--r--    1 root     root         3421 mar  4  2001 #1769994
-rw-r--r--    1 root     root        13547 dic  1  2001 #1769995
-rw-r--r--    1 root     root         3134 mar  4  2001 #1769996
-rw-r--r--    1 root     root        96692 mar  1  2002 #1769997
I files ci sono ma hanno "perso il nome".
C'è modo di recuperarne il nome o l'intera dir ?
( da quanto ho letto .. a me non sembra
.. ma fra voi sapienti magari avete qualche coniglio da tirare fuori :-)
Grazie mille
			 -- Yena --
Ps. Non mi proponete di ripristinare un backup pls :-)
.. stendiamo un velo pietoso su questo punto.

 nome o l'intera dir ?
No, non c'e` modo. I file finiscono li` perche` si e` persa la directory 
che li conteneva, e il nome del file e` dentro la directory, non dentro il 
file.
Il numero che vedi e` l'inode a cui era salvato il file.
Bye.

 voi sapienti magari avete qualche coniglio da tirare fuori :-)
Se riesci a visualizzare le immagini, con taaaaanta pazienza puoi 
rinominarle a mano (a me e' successo con files di testo e con un editor 
binario sono riuscito, dopo un bel po' di lavoro, a ricostruire il 90% 
dei files).
Ciao, Mauro


probabilmente non c'è un modo (altrimenti sarebbe già stato
implementato in fsck).
Con poca volontà di flammare, ma con molta determinazione a dire la
verità, dico quanto segue:
Per esperienza diretta: ti succederà un'altra volta, poi un'altra
volta ancora e quindi capirai da te la soluzione a questo problema:
mai usare un FS il cui nome comincia per ext, e finisce con un numero
compreso tra 2 e 4.

 verità, dico quanto segue:
Se non vuoi "flammare" dovresti almeno sommariamente spiegare le tue 
ragioni, altrimenti passa per FUD.
Ciao.


wrote:

le ragioni profondo sono racchiuse nelle due righe del mio messaggio:
/* autoquote
* Per esperienza diretta: ti succederà un'altra volta, poi un'altra
* volta ancora e quindi capirai da te la soluzione a questo problema:
*/
non è una idiosincrasia per le cose che iniziano per ext e finiscono
con un numero compreso tra 2 e 4. ext3 mi è andato a donnine di facili
costumi un paio di volte e così l'ho salutato per sempre.
Pero', ripeto, è giusto che ognuno faccia la sua esperienza e tocchi
con mano, e perda tutti i suoi dati.
Solo a quel punto si ricorderà di me, e capirà ciò di cui sto
parlando.


giusto per la cronaca: stamattina il mio collega ha acceso il notebook
con linux, con ext3. Gli è partito l'fsck e ha iniziato a segargli un
bel po' di file.
Che devo pensare? Devo pensare che ext3 ultimamente è migliorato
parecchio?

 parecchio?
Personalmente penso che non ho mai avuto un problema del genere ne senza il 
journal ne' col journal , tranne in casi di difetto di hw , di ext* si puo' 
dire di tutto tranne che non sia affidabile , se poi hai dei problemi di 
perdita dati dai un occhio a 
http://ext4.wiki.kernel.org/
 , ci trovi anche 
le mailinglist specifiche.
il resto è FUD.
-- 
DELEGATO - Slegato.

 il resto è FUD.
il fatto che ext3, dopo 15 anni di sviluppo, non fa nemmeno la metà
delle cose altri FS facevano facevano già 15 anni fa è sempre FUD ?
Qui se vuoi c'è tanto altro FUD 
http://en.wikipedia.org/wiki/AdvFS
.... che per fortuna sta per essere portato su Linux.
Purtroppo Linux in certi campi si è evoluto male e piano. Sempre per
far riferimento all'OS della pagina wiki di cui sopra, Linux a
iniziato a supportare l'SMP a fatica e molto lentamente (e dopo una
lunga controversia sul fatto che il codice era stato copiato: vedi
SCO). Anni e anni prima, l'OS di cui sopra supportava già 64 CPU.

 SCO). Anni e anni prima, l'OS di cui sopra supportava già 64 CPU.
Eddai! Citare la controversia SCO come esempio di codice copiato?
Quando a seguire un minimo minimo il discorso (o anche a seguirlo per
bene) s'è visto che si erano inventato tutto?
Posso confermare, il plurale di 'aneddoto' non è 'dati'. Se una
frazione _statisticamente rilevante_ di utenti avesse quei problemi
con ext3 (e solo con ext3), non lo cagherebbe nessuno.
Mi spiace che tu abbia perso dati, ma non è proprio normale. Creando
il filesystem, hai pensato bene agli usi futuri? O forse adesso (o
quando hai avuto problemi) hai superato il modo d'uso ideale di ext3 e
ti ci vorrebbe altro? Cioè, gli autori di ext3 non hanno mai detto che
fosse il FS ideale per tutto.
Se è per questo, per seguire il tuo esempio, uso ext3 da anni, e
dovrei dire che è perfetto.
Per finire, il detto 'all hardware sucks, all software sucks' si
conferma anche in questo caso: ho sentito peste e corna di ogni FS.
Anche di ZFS, che per alcuni è il FS del Messia redivivo.
--
Saludos
Adriano

 ext3 ultimamente è migliorato parecchio?
Dal '96 ho cominciato ad usare Linix con ext2/ext3 sulle macchine del 
laboratorio e i problemi li ho sempre avuti solo quando era l'hardware 
a fare casino.  E poi l'fsck se non lo lanci in repair mode non ti 
sega niente.
Se il tuo collega non sa gestire il PC perché gli fai usare Linux?
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   Registered Linux user #337974  < 
http://giovanni.homelinux.net/
 >


Lascia perdere SCO. Lo avevo messo anche tra parentesi e probabilmente
è come dici tu. Il punto è che certe tecnologie, su Linux, o non sono
mai arrivate, o sono arrivate anni e anni dopo. Per l'SMP si è dovuto
attendere anni e anni (e comunque, lo rimetto tra parentesi, la
controversia con SCO c'è stata).
Per il FS in 15 anni cosa hanno concluso?
Te lo dico io cosa hanno concluso in 15 anni: hanno fatto un FS
leggermente migliore di UFS, in quanto implementa il journaling.
AdvFS, il cui progetto è iniziato nella seconda metà degli anni '80, è
avanguardistico rispetto a ext4 che ancora quasi non esiste ed è in
stato beta (ext4dev).


non ti preoccupare. Il mio collega sa gestire il PC.
Sul notebook ha un LVM con il volume criptato (per policy aziendale)
su ext3.
Lo ha spento, lo ha riacceso e voilà.

 ancora quasi non esiste ed è in stato beta (ext4dev).
Come si dice: "se sai farlo meglio, fallo meglio, ma fallo".
Evidentemente ext2/3 era "good enough" per chi usava Linux. Quando sono 
subentrate esigenze diverse si e` iniziato a lavorare sulle alternative.
Bye.

 stato beta (ext4dev).
poi e' strano che tu stia parlando di *filesystem* che e' un metodo per
memorizzare i file mentre citi altri FS che fanno cose (e presumo siano
queste le funzioni cui alludi) che esulano dal campo dei filesystem. per
esempio, il volume management, l'aggiunta e rimozione di device, gli
snapshot, ecc. non sono cose propriamente da filesystem. 
Possiamo poi opinare sulla comodita di far fare queste funzioni ad un solo
filesystem, cosi' come fa zfs, ma la teoria non cambia.
E la mia personale opinione e' fare le cose separatamente, per diminuire la
complessita' e guadagnare in flessibilita'.

 immancabile perdita di dati.
In tutti i filesystem su O.S. con cache uno spegnimento brusco causa 
perdita di dati. Non ci sono santi ne` madonne.
Puoi preservala l'integrita` del fs con il journal, ma i dati li perdi 
anche con un journal sui dati, semplicemente perche` non sono su disco, 
sono in RAM.
Anche io uso ext2/3 dal 96 e non ho mai dovuto formattare perche` il fs 
era irrecuperabile. Ho perso dati, altri me li sono trovati in lost+found, 
ma il fs e` sempre stato riparato da e2fsck e ho recuperato il 
recuperabile.
Non posso dire la stessa cosa di reiser3 (che mi ha fottuto ben due volte 
su tre che l'ho usato), e per questo lo sconsiglio.
XFS e JFS li ho provati solo quando erano in beta, e mi hanno perso dati 
rendendo il fs inconsistente, ma sono consapevole che erano in beta, 
quindi non dico a nessuno "non usarli".
Bye.

 causa immancabile perdita di dati.
Nessun filesystem può essere robusto "per design" in senso assoluto, se 
poi utilizzi dischi con cache da 8(+) MB.
Ci sta un sacco di roba in 8MB, che il kernel "crede" essere stata 
scritta su disco, persino sync() ritorna correttamente, mentre i dati 
potrebbero ancora essere solo nella cache del controller.
Probabilmente basterebbe disabilitare il write-back del disco, hdparm 
-W, ma non c'entra col tipo di filesystem utilizzato.
Qualcuno mi parlava anche di barrier ma non sono documentato a sufficienza.


filesystem del cactus, per ambiente del cactus ? ;)
Ciao.


cenere sul capo a iosa, e continuiamo la discussione :)

 Leggitihttp://www.groklaw.comli' c'e' tutto.
si, mo' non mi metto a leggere il tutto. Difatto l'implementazione SMP
è cambiata dalla notte al giorno, in un solo giorno.
Comunque ricordo che la storia aveva dei contorni grotteschi. SCO
rivendicava la paternità degli script del sysv, Microsoft che
patentava il "virtual desktop", qualche sua grande invenzione del
secolo corrente ... e così via.

 subentrate esigenze diverse si e` iniziato a lavorare sulle alternative.
Ciao


 filesystem del cactus, per ambiente del cactus ? ;)
nel caso dei vecchi unix, si proprio un ambiente del cactus. 
Ti condanno quindi a utilizzare solo ed esclusivamente Xenix per 3 anni e
poi vediamo come ne esci fuori. :)

 secolo corrente ... e così via.
non grotteschi, ma opportunistici. 
Ad ogni modo documentati, che fa bene imparare dalla storia. 
Aiuta a riconoscere le balle per quello che sono.

 complessi.
Hai centrato il punto. Il supporto all'SMP e` iniziato quando l'hardware 
e` diventato abbastanza economico da entrare in possesso di uno 
sviluppatore che l'ha fatto gratis.
Quando e` stato donato un sistema NUMA agli sviluppatori Linux, hanno 
fatto il supporto anche per quello, e hanno migliorato l'SMP.
 
Bye.

 poi vediamo come ne esci fuori. :)
no 'sta roba qui non l'ho mai vista nemmeno da lontano. Xenix,
Sinix... so che esistono e null'altro.

 ambienti, ma anche gli altri hanno copiato da Linux.
Verissimo. Adesso vagli a dire a Linus che Gnome è un buon desktop.
"until you'll do it for idiots, only idiots will continue using it..."
Questo è quel che Linus pensa di di Gnome.
Ma a te piace Gnome? A me si (anche se è un po' mastodontico) e me ne
frego un cactus di quel che pensa Linus. Così come non me ne frega un
cacchio di tutta la vis-polemica di Linux, una volta contro reiser4,
una volta contro solaris, e una volta c'era pure quella contro XFS.
se 2+2 = 4, a parte UFS qualsiasi altro FS per Unix è migliore di
ext3/4.... checché ne dica Linus e i suoi fan stregati.

 Ad ogni modo documentati, che fa bene imparare dalla storia.
ma non è che non so le cose. Certo è mi sfugge qualche dettaglio sulla
questione tra Sco e Novell.
Ma ripeto, che tu sappia: è stata Novell a rivendicare la paternità di
certe cose, e la copiatura è comunque sussistita, con il bene placito
di Novell (*). La sostanza a me sembra questa: SCO ha rivendicato la
paternità di cose che non erano sue.
(*) ovviamente i fan stregati di Linux non hanno mancato di far
sentire le proprie polemiche anche contro Novell.

 di Novell (*)
[Citation needed]
Non ricordo casi in cui ci fosse stata copia di roba da Unix a Linux,
salvo un caso di costanti di errore. Tutta la causa di SCO è stata un
mare di aria fritta resa più densa dai soldi di MS e altri.
Novell ha detto 'momentino, quei diritti di Unix che SCO dice siano
loro, sono nostri', mica 'Si, i cari ragassi di Linux hanno copiato ma
va tutto bene'.
Che il matto del villaggio (SCO) si metta a urlare non significa che
ci sia una discussione valida. Che un truffatore voglia truffare non
vuol dire che i suoi argomenti abbiano la minima validità, o che la
'controversia' sia da ricordare.
--
Saludos
Adriano

 Sinix... so che esistono e null'altro.
meglio per te :)
comunque ora basta, che devo tornare al lavoro.

 comunque ora basta, che devo tornare al lavoro.
si vede che io oggi non ho proprio niente da fare :)

 wrote:
]zac[
gli unici dati che ho perso da una decina di anni a questa parte li ho 
persi per problemi HW o per cancellazione involontaria.. nonostante sia 
dovuto ricorrere qualche volta a fsck.. il fatto che una distribuzione 
come RedHat metta ext3 di default mi pare sia indice di affidabilità del fs.
e, comunque, il tuo caso particolare, statisticamente parlando, ha 
validità 0
Stefano

 persi per problemi HW
What is "problema hardware"? I dunno italiano. Please explain. You
unplug the power cord, you plug it again e con ext3 hai perso tutto ?

 unplug the power cord, you plug it again e con ext3 hai perso tutto ?
A me e` capitato di corrompere il fs in due casi.
Nel primo era una CPU Cyrix 686 morente (che dava errori a caso quando si 
surriscaldava un po'), e nel secondo erano RAM difettose.
In caso di "normale" mancanza di corrente, come ho detto, non mi e` mai 
successo di corrompere irrimediabilmente il fs.
Bye.


Allora: concordo perfettamente con voi che l'esperienza personale non
fa statistica... ma mi piace un po' il cazzeggio.
Resto fermo invece sul fatto che le caratteristiche tecniche di ext4
(che ancora deve nascere) sono le caratteristiche che aveva un
filesystem Unix 15 anni fa ....vedi XFS, JFS, AdvFS: extent, tool di
defrag, ACL, tool integrati di backup, freeze del FS, undeletion.
Alcune di queste cose non saranno presenti nemmeno in ext4. Dovrete
aspettare altri 15 anni :)
E ripeto, per arrivare a questo misero risultato, si sono dovuti
attendere 15 anni.

 attendere 15 anni.
Alcuni direbbero che l'aggettivo 'misero' è una petizione di
principio. Altri, che veramente tanto misero non è. Altri ancora, che
se XFS e JFS da 15 anni sono la manna ma non hanno sbancato, ci sarà
pure un motivo.
Io direi tutte e tre alla volta.
--
Saludos
Adriano

 pure un motivo.
il motivo sono i fan stregati.... che non sanno che un filesystem
journaled frammenta, e che un filesystem journaled con extent puo'
essere facilmente deframmentato. Infatti ext4 prevede l'uso del tool
di frammentazione (presente in Linux su XFS da una vita e mezza) ;)

 mai arrivate, o sono arrivate anni e anni dopo.
Adamo, ricordati sempre di cosa stai parlando. Da una parte c'e`
un'azienda che ha pagato (e paga) fior di quattrini in R&D, dall'altra
c'e` un sistema incominciato come progetto (piu` o meno) amatoriale
Enrico

 Le ACL sono presenti da anni su Linux (che sono i gruppi sennò?)
ACL di base. Le ACL complesse[1] in ext3 le hai comunque da parecchio
tempo (forse addirittura da ext2)
Enrico
[1] e.g. una directory creata da topolino (che appartiene al gruppo
topolinia) con quella che definisco ACL di base puo` essere resa
accessibile all'utente, al gruppo e negato a tutti gli altri. Con
quella che ritengo una ACL complessa posso pero` permettere l'accesso in
lettura a paperone e l'accesso in scrittura a paperino. Per fare cio`
vengono utilizzati i comandi setfacl e getfacl

 punto che pure ext2 era robusto. 
Culo o meno, non ho mai perso un dato con ext2
Enrico

 Questo č quel che Linus pensa di di Gnome.
Leggi bene e non tirare conclusioni prendendo delle frasi al di fuori
del contesto in cui sono state dette. Torvalds non critica GNOME in
quanto tale, ma critica la mentalita` che sembra portarlo avanti
(ovvero "Gli utenti sono idioti e sono confusi dall'abbondanza di
funzionalita`"). Quello che dice, invece, e` che si GNOME e` semplice,
ma lo e` in una maniera che lo rende limitante per un utente piu`
smaliziato dell'utente base
Enrico
P.S. tra l'altro, Torvalds non si e` limitato a criticare GNOME e basta,
ma ha anche inviato delle patch agli sviluppatori

 verità, dico quanto segue:
Adamo, possibile che ogni volta si deve fare 'sta storia? Quando capirai
che quello che dici *non* e` la verita`, ma *solo* una tua esperienza?
Potrei citarti casi di persone che, indipendentemente dal file system
utilizzato, non hanno mai perso dei dati[1] mentre ci sono persone che
dio solo sa in quali casini sono capitati per aver usato un file
system rispetto ad un altro
Enrico
[1] uno di questi ero io finche`, dopo un brutto riavvio, JFS non ha
deciso di bruciarmi il contenuto di mezza /bin e di mezza /var

 AdvFS
Per Btrfs forse sono riusciti ad arrivare ad un punto accettabile
(dicono che l'ODS non cambiera` a meno di bug). Per quanto riguarda 
AdvFS, posto che oramai per alcuni aspetti e` un file system
obsoleto[1], il codice e` stato rilasciato non per essere aggiornato e
riutilizzato in produzione, ma per essere utilizzato come base per
l'aggiunta di nuove funzionalita` a file system esistenti o per essere
una base di esempio per un nuovo file system
Enrico
[1] diciamola meglio. A parte alcune funzionalita` (e.g. l'undelete)
che ancora latitano negli altri file system per unix[2],  per gli
standard attuali AdvFS e` un file system palesemente obsoleto. Le
dimensioni del file system, per dirne una, era gia` possibile
superarle con ext2 su Alpha (16TiB contro 32Tib). Inoltre, AdvFS e`
nato e morto, ext (ma non solo lui) e` in costante sviluppo
[2] in teoria l'undelete c'e` in ZFS, Btrfs e XFS. Nei primi due pero`
si tratta di una funzione emulata via snapshot, mentre nel terzo e` in
teoria implementato, ma in pratica non vi e` alcuno strumento per
utilizzarlo (o almeno questo e` quello che c'e` scritto su wikipedia)

On 13 Gen, 23:50, Enrico 'Henryx' Bianchi

con EXT2 (e con ogni probabillità anche con UFS), basta spegnere e
riaccendere e - se hai un proxy server, un news server o un mail
server con la maildir - perderai tutto inesorabilmente.
Non ci sono santi.

MaxAdamo ha scritto:

Ma anche no.. che ci sia il rischio ok, che sia matematico perdere tutto 
inesorabilmente proprio no
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
"Stealing a rhinoceros should not be attempted lightly."

 Non ci sono santi.
basta con sto' discorso , è solo FUD , se fosse come dici nessuno userebbe 
extX mentre è praticamente lo standard.
-- 
"Cerca sempre di fare le cose in ordine cronologico; si fa meno
confusione in questo modo."

On 14 Gen, 00:19, Enrico 'Henryx' Bianchi

Sei vedere che qui siete tutti machi e superuomini e non vi succede
mai nulla.
posso citare alcuni cose che mi ricordo:
1) ext2: riavvio brusco e perdita della cache di squid.
2) early version of reiser. Erano versioni iniziali, credo di aver
perso dei dati (ma in fase di testing/istallazione).
3) ext3, senza apparente motivo, due volte, su due pc diversi, ho
riavviato il PC e mi sono ritrovato con il FS sputtanato e un sacco di
file in lost+found
4) XFS, in fase di installazione su un notebook, con un controller
nvidia, pilotato da driver ata_generic , non mi completava
l'installazione e perdeva file in continuazione. In pratica non ho
perso niente, ma non riuscivo a portare a termine l'istallazione.
Appena uscito il driver per quel controller ho risolto il problema
definitivamente.
Altri FS su Linux non ne ho provati (fatta eccezzione per vxfs che ho
trovato preinstallato su alcuni server).


non è FUD. Un proxy server ha centinaia di migliaia di file scritti e
acceduti in continuazione.
Con un filesystem non journaled è *MATEMATICAMENTE* *IMPOSSIBILE*
preservare tutti quei dati dopo uno spegnimento brusco.
Mi dirai che che perdere la cache di un proxy è poca cosa... forse è'
più grave se perdi le mail da una maildir.
Se così non fosse non si sarebbero spesi tempo ed energie a creare FS
journaled.

 inesorabilmente proprio no
parlo di un proxy server con centinaia di migliaia di file scritti e
acceduti in continuazione.
Dici che esiste una remota possibilità che dopo uno spegnimento
brusco, senza FS journaled, non succeda nulla, ma proprio nulla ?
A me pare quasi impossibile. Che poi, in questo tipo di esempio, si
tratti di file di scarsa importanza è un altro paio di maniche.

 Non ci sono santi.
Tu hai scritto "TUTTO INESORABILMENTE" e io questo ti contesto.
Che ci sia la possibilità di rompere roba ok (anche con gli FS giornalati.. 
c'è sempre la cache del disco e del controller di mezzo) ma che sia 
automatico perdere tutto (l'hai scritto te) proprio no
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
"I don't like spinach, and I'm glad I don't, because if I liked it I'd
eat it, and I just hate it."
		-- Clarence Darrow

 preservare tutti quei dati dopo uno spegnimento brusco.
basta , stiamo parlando del sesso degli angeli , la chiudo qui'.
-- 
- Vedi, cara, l'amore e' una cosa, il sesso un'altra.
- E la roba che facciamo noi come si chiama?
		-- Da it.hobby.umorismo

 preservare tutti quei dati dopo uno spegnimento brusco.
E io ti ripeto che con qualsiasi fs, journaled o meno, con extent o meno, 
con cache o meno, e` impossibile preservare tutti i dati.
E il motivo e` gia` stato spiegato.
L'unica cosa che cambia e` la consistenza del fs dopo lo spegnimento. Con 
un journaled e` consistente, con uno non journaled no, e va fatto il fsck.
Con ext2, questo fsck dovrebbe (e a ME l'ha sempre fatto senza problemi) 
cancellare i file "a meta`", spostare in lost+found quelli integri ma di 
cui ha perso info sulla directory genitore, e lasciare inalterati tutti 
quelli chiusi correttamente, e infine ripristinare la consistenza del fs.
Ecco, questo, a ME, reiser non l'ha fatto per ben due volte su tre.
Bye.

 preservare tutti quei dati dopo uno spegnimento brusco.
Con un file system journaled, invece, anche.
Il file system è coerente, ma mica è detto che ciò che stavi scrivendo
ci sia, sul disco.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 Tu hai scritto "TUTTO INESORABILMENTE" e io questo ti contesto.
ok, il tutto è riferito a quei file particolari (la cache del proxy in
questo caso).... la moglie, il lavoro e la /home credo che non
dovresti perderli :-)

 ++, ho "bellissimi" ricordi di un botto storico di jfs su lvm
+++ mai usato, ma ho sempre letto a riguardo che mancano i feedback
(perché poco diffuso in ambito linux) ed è difficile esprimersi in
merito.

 il fatto che ext3
Mi sfugge una cosa: esattamente, cosa vuoi?

 mai nulla.
Non e` un discorso di essere machi, ma di avere esperienze differenti.
Solo che la differenza tra $tizio e te, e` che tu vuoi far passare come
verita` assoluta una tua esperienza personale
Enrico