From: Eric Sandeen <sandeen@sandeen.net>
To: xfs@oss.sgi.com
Subject: Re: [PATCH] xfs_quota: fall back silently if XFS_GETNEXTQUOTA fails
Date: Tue, 2 Aug 2016 10:54:53 -0500 [thread overview]
Message-ID: <564b87af-e3b2-5abf-4000-5f068191fc80@sandeen.net> (raw)
In-Reply-To: <20160802131427.GD16413@zlang.usersys.redhat.com>
On 8/2/16 8:14 AM, Zorro Lang wrote:
> On Tue, Aug 02, 2016 at 05:27:21AM -0700, Christoph Hellwig wrote:
>> On Tue, Aug 02, 2016 at 02:49:00PM +0800, Zorro Lang wrote:
>>> After XFS_GETNEXTQUOTA feature has been merged into linux kernel and
>>> xfsprogs, xfs_quota use Q_XGETNEXTQUOTA for report and dump, and
>>> fall back to old XFS_GETQUOTA ioctl if XFS_GETNEXTQUOTA fails.
>>>
>>> But when XFS_GETNEXTQUOTA fails, xfs_quota print a warning as
>>> "XFS_GETQUOTA: Invalid argument". That's due to kernel can't
>>> recognize XFS_GETNEXTQUOTA ioctl and return EINVAL. At this time,
>>> the warning is helpless, xfs_quota just need to fall back.
>>
>> We'd still want to report other errors, right?
>
> Yes. This patch will make xfs_quota's report and dump command report
> nothing if XFS_GETNEXTQUOTA fails and falls back to XFS_GETQUOTA.
>
> But if XFS_GETQUOTA fails, it'll report errors.
>
> As I mentioned in email, we don't report errors if XFS_GETNEXTQUOTA
> fails, or we don't report errors if kernel has no XFS_GETNEXTQUOTA
> feature? The first one won't report any errors from XFS_GETNEXTQUOTA call,
> include kernel has no this feature.
>
> So:
> "cmd == XFS_GETQUOTA" or "!(cmd == XFS_GETNEXTQUOTA && errno == EINVAL)"
Oh, I see, this is what I was trying to do before coffee in my earlier
reply, and failed. :)
> I think they all make sense. Do you have any suggestions?
Ignoring EINVAL only for XFS_GETNEXTQUOTA seems like a reasonable
idea - we might print two warnings for other errors, though -
that might be a little odd, but not terrible.
I think the patch as it stands is ok; unexpected errors will be caught
and printed on the fallback, and we don't need extra complexity around
printing two different command names that way.
But if there's preference for printing failure information for
both calls, that's fine with me, as long as we filter out EINVAL for
GETNEXTQUOTA.
-Eric
> Thanks,
> Zorro
>
>>
>> _______________________________________________
>> xfs mailing list
>> xfs@oss.sgi.com
>> http://oss.sgi.com/mailman/listinfo/xfs
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2016-08-02 15:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-02 6:49 [PATCH] xfs_quota: fall back silently if XFS_GETNEXTQUOTA fails Zorro Lang
2016-08-02 12:27 ` Christoph Hellwig
2016-08-02 13:14 ` Zorro Lang
2016-08-02 15:54 ` Eric Sandeen [this message]
2016-08-02 15:06 ` Eric Sandeen
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=564b87af-e3b2-5abf-4000-5f068191fc80@sandeen.net \
--to=sandeen@sandeen.net \
--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;
as well as URLs for NNTP newsgroup(s).