From: Carlos Maiolino <cmaiolino@redhat.com>
To: Brian Foster <bfoster@redhat.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 1/2] xfs_io: implement 'inode' command V4
Date: Thu, 26 Nov 2015 12:30:55 +0100 [thread overview]
Message-ID: <20151126113052.GA15663@redhat.com> (raw)
In-Reply-To: <20151119132722.GA13055@bfoster.bfoster>
Hi Brian,
>
> Well, the code looks Ok to me but the design still seems overdone IMO. I
> have no major objection if this goes in as is (with one exception noted
> below), but IMO we should take the approach somewhat discussed in the v3
> review.
First of all, thanks for reviewing the patch again, I took some time to reply
because I was waiting for any other comments and had a few other things to do.
>
> In particular, define an actual default behavior for the command to
> return the largest inode number (or return 1/0 for "ability to mount w/
> inode32" as Dave suggested). For example, kill both of the -l and -s
> flags and just return 1/0 by default. Define a single verbose (-v) flag
> to print the combined inode number and size. This mode can be
> implemented as the body of the inode_f() function. If -n is specified,
> basically do what the current version does. Just my .02.
>
I agree with you here and tbh, I don't really think a -v flag is really needed,
although it can certainly facilitate the usage of the xfs_io -c "inode".
Checking for the size of the inode returned against UINT32_MAX is not that hard
anyway, but I think keeping a very simple return value for the command might be
the best approach.
I'm going to re-write it and send a V5 today including a review of your comment
below.
thanks again for the review
> > io/open.c | 151 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 151 insertions(+)
> >
> > diff --git a/io/open.c b/io/open.c
> > index ac5a5e0..2fc8aab 100644
> > --- a/io/open.c
> > +++ b/io/open.c
> ...
> > + if (ret_lsize || ret_largest) {
> > +
> > + bulkreq.lastip = &last;
> > + bulkreq.icount = 1024; /* User-defined maybe!? */
> > + bulkreq.ubuffer = &igroup;
> > + bulkreq.ocount = &count;
> > +
> > + for (;;) {
> > +
> > + if (xfsctl(file->name, file->fd, XFS_IOC_FSINUMBERS,
> > + &bulkreq)) {
> > + perror("XFS_IOC_FSINUMBERS");
> > + exitcode = 1;
> > + return 0;
> > + }
> > +
> > + if (count == 0)
> > + break;
> > +
> > + lastgrp = count;
> > + }
> > +
> > + lastgrp--;
> > + igrp_rec = igroup[lastgrp];
>
> IIRC the point of igrp_rec was to save off the last record so it could
> be used directly after the loop without need for the count (because it
> could be 0). Here we use a separate lastgrp count to protect against the
> 0 case, yet still do the record copy after the loop... what's the point
> of that?
>
> Brian
>
> > + lastino = igrp_rec.xi_startino +
> > + xfs_highbit64(igrp_rec.xi_allocmask);
> > +
> > + if (ret_lsize)
> > + printf (_("Largest inode size: %d\n"),
> > + lastino > XFS_MAXINUMBER_32 ? 64 : 32);
> > + else
> > + printf(_("Largest inode: %llu\n"), lastino);
> > +
> > + return 0;
> > + }
> > +
> > + return command_usage(&inode_cmd);
> > +}
> > +
> > void
> > open_init(void)
> > {
> > @@ -815,6 +955,16 @@ open_init(void)
> > _("get/set preferred extent size (in bytes) for the open file");
> > extsize_cmd.help = extsize_help;
> >
> > + inode_cmd.name = "inode";
> > + inode_cmd.cfunc = inode_f;
> > + inode_cmd.args = _("[-s | -l | -n] [num]");
> > + inode_cmd.argmin = 1;
> > + inode_cmd.argmax = 2;
> > + inode_cmd.flags = CMD_NOMAP_OK;
> > + inode_cmd.oneline =
> > + _("Query inode number usage in the filesystem");
> > + inode_cmd.help = inode_help;
> > +
> > add_command(&open_cmd);
> > add_command(&stat_cmd);
> > add_command(&close_cmd);
> > @@ -822,4 +972,5 @@ open_init(void)
> > add_command(&chproj_cmd);
> > add_command(&lsproj_cmd);
> > add_command(&extsize_cmd);
> > + add_command(&inode_cmd);
> > }
> > --
> > 2.4.3
> >
> > _______________________________________________
> > xfs mailing list
> > xfs@oss.sgi.com
> > http://oss.sgi.com/mailman/listinfo/xfs
--
Carlos
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2015-11-26 11:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-16 8:43 [PATCH 0/2] xfs_io: implement inode command Carlos Maiolino
2015-11-16 8:43 ` [PATCH 1/2] xfs_io: implement 'inode' command V4 Carlos Maiolino
2015-11-19 13:27 ` Brian Foster
2015-11-26 11:30 ` Carlos Maiolino [this message]
2015-11-16 8:43 ` [PATCH 2/2] xfs_io: inode command manpage V1 Carlos Maiolino
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151126113052.GA15663@redhat.com \
--to=cmaiolino@redhat.com \
--cc=bfoster@redhat.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox