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 > > _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
