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

[Brian Foster <bfoster@redhat.com>]

On Mon, Nov 30, 2015 at 03:26:22PM +0100, Carlos Maiolino wrote:
> > 
> > I think we want "n:v" here since -n expects an argument, even if we
> > don't process the arg here.
> 
> Using getopt() to handle the -n argument, will make the inode command having 2
> different entry points for the same argument, i.e. the inode number. One as an
> argument for -n, and another as an argument for the command itself, like:
> 
> inode -n <num>
> inode <num>
> 
> We need to handle [num] as a stand-alone argument anyway, so, I just don't think
> we need to handle the same argument in different ways, which I achieved by not
> using [num] as a getopt() argument, but instead, handling [num] 'manually'
> according to the options used in getopt().
> 
> Not sure if I could be clear or get things more confused :)
> 

Sure, but I'm just referring to the error case when the user passes -n
without an argument. This should return an error but it doesn't at the
moment. I'm assuming that using "n:" would ensure the error message is
printed without disrupting the other code (e.g., continue to process
[num] manually even though "n:" is passed to getopt()). Is that the
case? If not, the error could be detected/handled manually as well.

Either way, a comment would also be useful here to document the special
handling as you note above.

> 
> > > +	if (ret_next && verbose)
> > > +		return command_usage(&inode_cmd);
> > > +
> > 
> > Why is this not supported? Hmm, I see that -n returns an inode number
> > and otherwise we print 0/1 or <inode>:<size> with -v. Perhaps this would
> > be easier if the command semantics/output were more consistent. E.g., 
> > 
> > "inode": print 0/1 based on largest inode size
> > "inode -v": print <ino>:<size> of largest inode
> > "inode <ino>": print <ino> if inode exists
> > "inode -v <ino>": print <ino>:<size> if inode exists
> 
> I thought about this, but I decided to not do it because the command looks a bit
> redundant for me when 'inode <ino' was returning 0 or 1. Returning the inode
> number itself, if it exists, makes more sense to have a -v option here too.
> 

Not sure I follow... AFAICT the command semantics change depending on
whether an inode number is passed or not (irrespective of -n and -v). If
not, we're looking to see if the largest inode is 32-bit or 64-bit. If
an inode number is passed, we're checking to see if an inode exists.

Brian

> > "inode -n <ino>": print <next ino> if next inode exists
> > "inode -nv <ino>": print <next ino>:<size> if next inode exists
> 
> Just FYI, if the 'next inode' doesn't exist (i.e. using the last fs inode as
> argument), the ioctl will return 0 in bstat.bs_ino, which, I choose to leave it
> as-is, and adding this observation to the man page, instead of returning a
> messag like "no more inodes in the fs".
> 
> I decided to leave it as-is, because for usage would be easier to parse a '0'
> return value from -n argument, than parsing an error message which has the same
> meaning of a zeroed return.
> 
> 
> Anyway, I'm going add -v to the another options, just please take a look at my
> replies regarding the 'inode -n' return value and the reason I didn't use
> getopt() to handle -n argument and if you agree or not, so I'll rewrite the
> patch to v6 based on this.
> 
> Cheers o>
> 
> -- 
> Carlos

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs