----- "Koustubha Kale" <koustubha_kale@xxxxxxxxx> wrote:
| >Using this new version of fsck.gfs2 I was able to fix a file system
| >restored from the metadata you sent me.
|
| Hi Bob,
| I am curious as to how this works. The restoremeta options pretty much
| says it will destroy the data on the device. So how did you go about
| resoring the file system with the metadata I sent?
|
| With warm regards
| Koustubha Kale
>
>Hi Koustubha,
>
>The restoremeta option restores the metadata from a file into a device,
>without regard to where things are on disk. Only gfs2 metadata is
>restored, so when I restore the metadata on my test system, the files
>will all appear to be there in the same locations as your original file
>system, but the contents of those files will obviously be trash since
>no data is saved; the files will contain whatever happens to be on the
>device I'm restoring it to.
>
>So the file names, directories and internal gfs2 data structures are
>preserved, but the data blocks are ignored. If the file system has not
>changed AT ALL since the savemeta was done, the restoremeta will
>restore the metadata, leaving all the data blocks in their same
>locations. So for users, savemeta/restoremeta is a convenient way
>to make a backup of your metadata only, so if fsck.gfs2 makes a fatal
>mistake and destroys something, you can immediately do restoremeta and
>_sometimes_ get the file system back to its near-original condition
>before the fsck.gfs2. That's not 100% guaranteed. Take the following
>scenario:
>
>1. User does savemeta
>2. User runs fsck.gfs2
>3. fsck.gfs2 decides a file is damaged and needs to be deleted.
> The file has a dinode is at block 0x1000 and points to a data block
> at 0x1001. Both blocks are marked free.
>4. Later, fsck.gfs2 finds a file that is orphaned by a damaged directory.
> As a result, fsck.gfs2 creates a "lost+found" directory by allocating
> some free blocks. Guess which free blocks is uses? It may (or may
> not) use the block it freed earlier in step 3, 0x1000 and 0x1001.
>5. fsck.gfs2 does something stupid and destroys a whole directory
> because of some rare bug.
>6. User restores the metadata with restoremeta.
>
>After this sequence of events, the file deleted in step 3 will look
>restored, since the dinode block 0x1000 was saved and restored.
>However, if block 0x1001 was also used, that file's contents will now
>look remarkably like a lost+found directory block. See what I mean?
>
>Now granted, if fsck.gfs2 decided to delete the file in step 3, it's
>most likely due to irreparable damage, so restoring the metadata won't
>fix the file in either case.
>
>So you can't really trust the data restored by restoremeta unless
>nothing but the metadata has changed. But since savemeta doesn't save
>data blocks, any changes to the file system (including by fsck.gfs2)
>will most likely result in damage to the files.
>
>So restoremeta helps me solve gfs2 fsck issues because I can exactly
>simulate the failing conditions. But it can't be relied upon for
>much else.
>
>This is why backups are so important.
Hey Bob,
That was a great explanation.
Thanks for everything..
With warm regards
Koustubha Kale
Your Mail works best with the New Yahoo Optimized IE8. Get it NOW! http://downloads.yahoo.com/in/internetexplorer/
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
