[Top] [All Lists]

xfs_repair: enabling lazy sb counters

To: xfs@xxxxxxxxxxx
Subject: xfs_repair: enabling lazy sb counters
From: Peter Watkins <treestem@xxxxxxxxx>
Date: Tue, 25 Sep 2012 11:40:33 -0400
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=vV6FwKZ1qSmjeYS/+Gr76JWe+ByGiq+Hv8/g26grda8=; b=PUFBNmpCFEhANAdBk1sWQ9QqtKIPMU4zzbJPK7WUV+rudojeSGY1HbPMknVbCwvL4Y PRgrDyA9KzNRYtS+0MIXOo0kmOrx460hMuFwsbW1A4zHRHQIkn65GZ7QSKfMQK3V86DR 8lvAZNPkacrJIYCcYfO5x4GIFNf26aYaHqTJgcfBisTXG+0zuzMlrbmKxumSXyNdn+R5 Zy6uVtooHPVmnMQcNVcNGDVmdgD9puvp8FSvHGrP5dhIZVIGcvJmxxbt6Pwx+YyKdnPH K2f0Za8tCKrB9WSUqjUog35YJu30qJn1JvfvQqvapOPm6P/4IXEq6V8tG5824J/q1DN+ VWnA==

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?

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().

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.

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!

Lazy counts are a great feature, and I'd like to enable them on some
older systems.


<Prev in Thread] Current Thread [Next in Thread>