Pagina 1 di 1

scarsi backup superblock

Inviato: lun 2 nov 2009, 15:44
da ZeroUno
possibile che i backup superblock non vengano spalmati per TUTTO il filesystem?

Nella mia partizione da 38G, faccio una ricerca dei superblock con TestDisk (è il rootfs quindi non posso farlo con mke2fs -n /dev/hda1) e mi dice che l'ultimo superblock è 1605632 ed essendo da 4096byte, l'ultimo è al 6576668672 byte del disco, cioè 6.5G. Sul pc di un amico ho trovato addirittura (con l'mke2fs) che l'ultimo superblock è sotto i 2G su una partizione da 250G. Ora gli si è rotta la prima parte del disco, così ha perso TUTTI i backup superblock. A lui non interessa molto recuperare i file che sono sul disco ma la sola lista dei file (anche se personalmente trovo più semplice recuperare i file che la lista visto che l'elenco delle directory si trovano spesso all'inizio del disco.

E' normale secondo voi?

Ciao
01

EDIT: dimenticavo.. Il disco, che è usb, viene riconosciuto dal kernel (viene inserito in /proc/partitions con tanto di tabella delle partizioni), ma fdisk non riesce a leggere la tabella (I/O error su traccia 0, mi sembra). Pure questo, è normale? come fa il kernel a leggere la tabella delle partizioni?

Re: scarsi backup superblock

Inviato: lun 2 nov 2009, 23:58
da zoros
ZeroUno ha scritto:...
EDIT: dimenticavo.. Il disco, che è usb, viene riconosciuto dal kernel (viene inserito in /proc/partitions con tanto di tabella delle partizioni), ma fdisk non riesce a leggere la tabella (I/O error su traccia 0, mi sembra). Pure questo, è normale? come fa il kernel a leggere la tabella delle partizioni?
alcuni esperimenti fatti con fdisk, ecc. sembrano evidenziare che fdisk legge il MBR fisico ... cioè, modificando la tabella delle partizioni con un editor binario "fdisk -l" restituisce immediatamente i nuovi valori ... invece per il kernel è necessaria la ri-sincronizzazione con "sfdisk -R /dev/sdX" ...

però sembra anche che fdisk ricavi i dati del primo settore attraverso la lettura "grezza" del settore stesso /dev/sdX (quindi appoggiandosi comunque al kernel) ... non è da escludere anche un problema legato ad una cattiva mappatura dei devices in /dev ...

prima di fare dei tentativi di recupero forse è oppurtuno fare delle prove con altre versioni del kernel ...