On Thu, Jul 07, 2011 at 02:34:12PM -0500, Eric Sandeen wrote: > > It seems like you need an "exit strategy" - you probably cannot leave > your fs mounted -forever- ... Yes, of course. I didn't mean to imply that I'd leave it like this indefinitely. :) I will be on vacation next week, and it's not really reschedulable. So my plan was to ride the filesystem through next week, hope for the best, then fix it when I return, rather than attempt to start a fix now and risk ending up with a broken filesystem. Ideally I would preemptively switch to a warm backup before I leave, but that won't be ready in time. (I currently do have all the important data backed up, but it is to various different spaces where I had free disk space. The warm backup should be ready early next week if the filesystem does go belly-up before I return.) > 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. 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 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 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. 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 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 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!) --keith -- kkeller@xxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
