----- "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. Regards, Bob Peterson Red Hat File Systems -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
