On Tue, Sep 25, 2012 at 11:40:33AM -0400, Peter Watkins wrote: > Hello, > > Has anyone noticed that phase1 updates the lazy count flag in the > superblock, and then writes out the sb before the traversal in phase5 > counts btree blocks consumed and sets agf_btreeblks? Not until now. :/ > Seems like if xfs_repair is interrupted or crashes at the wrong time, > you'd have enabled lazy count but not set agf_btreeblks, which would > trigger the corruption check in xfs_alloc.c:xfs_read_agf(). Which tells you to run xfs_repair, right? > If you just re-run xfs_repair to enable lazy counts, it would stop > early saying they're already enabled. You'd have to disable them, and > then enable again to get a consistent state. Or you just run xfs_repair without trying to change the lazy count state - that will recalculate the btreeblks count as part of the normal repair process.... > Second, is it possible to enable lazy counts without doing the > full repair traversal, i.e. a cheap and easy way to set > agf_btreeblks if the fs is already consistent? On some systems, > the whole repair enchilada can take a long time! The current process is that xfs_repair -rebuilds- the freespace trees from it's in memory state, and it takes until phase 5 for xfs_repair to have a full picture of the freespace in the filesystem after fixing up possible errors. So basically when you enable lazy counters, repair essentially verifies all the freespace is correct before enabling it. That's a necessary pre-requisite for lazy-counters to work correctly, and the only way to ensure it is to walk the filesystem first. That said, if you really want to avoid running a full xfs_repair, you can always count the btree blocks manually with xfs_db and set the btreeblk count fields yourself. You get to keep the broken pieces when something goes wrong, though. :/ Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
