On 7/7/11 5:23 PM, Keith Keller wrote:
> On Thu, Jul 07, 2011 at 02:34:12PM -0500, Eric Sandeen wrote:
...
>> If it were me, if possible, I'd make backups of the fs as it's mounted
>> now, then umount it and make an xfs_metadump of it, restore that metadump
>> to a new sparse file, and point xfs_repair at that metadata image file,
>> to see what repair might do with it.
>>
>> If repair eats it alive, then we can look into more xfs_db type surgery
>> to fix things up more nicely...
>
> This sounds like a reasonable plan. It looks like xfs_metadump needs a
> umounted or readonly filesystem in order to work properly; is there any
> way to estimate how long such a dump would take, and how large it would
> be from an almost-full 11TB fs with however many inodes it has (~19 million
> IIRC)? I want to plan downtime and usable disk space accordingly.
well, I'm looking at an image of a 4T fs right now, with 208k inodes,
and the image itself took up 800M (a 4T sparse file when restored,
of course, but only using 800M)
> Would xfs_metadump create the same dump from a filesystem remounted ro
> as from a filesystem not mounted? I think you suggested this idea in
yes, looks like it works, with recent tools anyway.
> an earlier post. In a very optimistic scenario, I could imagine
> remounting the original filesystem ro, taking the metadump, then being
> able to remount rw so that I could put it back into service while I
> work with the metadump. Then, once I knew more about the metadump, I
I think that should work.
> could do an actual umount and fix the filesystem using the information
> gathered from the metadump testing. If they will produce the same
> metadump, then it could be a win-win if it's able to successfully
> remount rw afterwards; and if it can't, it wasn't any additional effort
> or risk to try.
agreed.
> Will xfsprogs 3.1.5 work with the older kernel, and will it make a
> better dump than 2.9.4? I have built xfsprogs from source, but if it
2.9.4 won't have xfs_metadump ... and no problems with newer tools on
older kernels. It's just reading the block device, in any case.
No unique kernel interaction.
> might have problems working with the kmod-xfs kernel module I can use
> the 2.9.4 tools instead. (Again, in keeping with the hope-for-the-best
> scenario above, if avoiding a reboot won't be too harmful it'd be
> convenient.)
I think you can.
> I think you also mentioned that xfs_metadump can not dump frozen
> filesystems, but the man page for 3.1.5 says it can. FWIW xfs_metadump
> refused to work on a frozen filesystem on my test machine, which is
> version 2.9.4 (though from an older CentOS base). (xfs_freeze does look
> like a nice tool though!)
it should(?) but:
# xfs_metadump /dev/loop0 blah
xfs_metadump: /dev/loop0 contains a mounted and writable filesystem
fatal error -- couldn't initialize XFS library
# xfs_freeze -f mnt/
# xfs_metadump /dev/loop0 blah
xfs_metadump: /dev/loop0 contains a mounted and writable filesystem
fatal error -- couldn't initialize XFS library
# xfs_freeze -u mnt
# mount -o remount,ro mnt
# xfs_metadump /dev/loop0 blah
<proceeds w/o problems>
I think we should make the tools work with freeze, but remount,ro works fine
too.
-Eric
> --keith
>
>
|