xfs
[Top] [All Lists]

Re: [REVIEW] Add lazy-counter conversion to xfs_repair

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: [REVIEW] Add lazy-counter conversion to xfs_repair
From: David Chinner <dgc@xxxxxxx>
Date: Sat, 23 Feb 2008 16:06:03 +1100
Cc: Barry Naujok <bnaujok@xxxxxxx>, "xfs@xxxxxxxxxxx" <xfs@xxxxxxxxxxx>
In-reply-to: <47BF0859.6020707@sandeen.net>
References: <op.t6wyesz53jf8g2@pc-bnaujok.melbourne.sgi.com> <47BF0859.6020707@sandeen.net>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
On Fri, Feb 22, 2008 at 11:37:29AM -0600, Eric Sandeen wrote:
> Barry Naujok wrote:
> > In response to the thread "Differences in mkfs.xfs and xfs_info output.",  
> > xfs_repair has been improved to allow version changes/conversion of  
> > filesystems.
> > 
> > So, this patch introduces the first in an ongoing series of in-place  
> > filesystem version changes with xfs_repair and the "-c" (convert) option.
> > 
> > To turn on/off the lazy-superblock feature, run the following xfs_repair  
> > commmand on your filesystem:
> > 
> > # xfs_repair -c lazycount=[0|1] <device>
> 
> How about adding this to xfs_admin as well, since some flag changes are
> already in there?
> 
> i.e. xfs_admin -<something... l and L are taken> could invoke xfs_repair
> -c lazycount ...?
> 
> It just strikes me as a tad confusing that to change v2 logs or
> unwritten extent support, you use xfs_admin, and to change lazy sb
> counters, you must run repair...

*nod*

> (I understand that repair must be run post-change, but a common tool to
> invoke all feature changes seems good to me)

I have to say I agree with Eric here - xfs_admin is the interface that
should be used for changing feature bits in the filesystem. The mechanism
it invokes to acheive the change can be anything, but we should have a
single tool that we direct ppl to use to to change how their filesystem
behaves.

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group


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