xfs
[Top] [All Lists]

Re: [PATCH] xfs_io: implement 'inode' command V3

To: Brian Foster <bfoster@xxxxxxxxxx>, xfs@xxxxxxxxxxx
Subject: Re: [PATCH] xfs_io: implement 'inode' command V3
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 28 Oct 2015 11:59:24 +1100
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20151023092946.GA752@xxxxxxxxxx>
References: <1445257880-30797-1-git-send-email-cmaiolino@xxxxxxxxxx> <20151022144255.GB13661@xxxxxxxxxxxxxxx> <20151023092946.GA752@xxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Fri, Oct 23, 2015 at 11:29:46AM +0200, Carlos Maiolino wrote:
> Thanks for the review Brian, I'll walk over it and fix the points you 
> mentioned.
> > 
> > 
> > I still don't really get why we have separate -l and -s options here. It
> > seems to me that the behavior of -l already gives us the information
> > that -s does. Even if that's not obvious enough, the -l command could
> > just print out both. For example:
> > 
> >       "Largest inode: 1234 (32-bit)"
> 
> I agree with you here, but, I'll let Dave answer this question, maybe he had 
> some another idea for it that I'm not aware of. 

No preference here; all that I was suggesting was that if you want
to know whether inodes are 32/64 bit it doesn't matter what the
largest inode number is.

i.e. "Can I mount this with inode32 and have no problems (yes/no)?"

And it's a lot easier to just query for *any* 64 bit inode than it
is to find the largest inode number...

If you want to combine the two, then that's fine by me.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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