xfs
[Top] [All Lists]

Re: [PATCH] xfs_quota: fall back silently if XFS_GETNEXTQUOTA fails

To: xfs@xxxxxxxxxxx
Subject: Re: [PATCH] xfs_quota: fall back silently if XFS_GETNEXTQUOTA fails
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Tue, 2 Aug 2016 10:06:24 -0500
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20160802122721.GE31492@xxxxxxxxxxxxx>
References: <1470120540-15135-1-git-send-email-zlang@xxxxxxxxxx> <20160802122721.GE31492@xxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

On 8/2/16 7:27 AM, 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?

I advised Zorro to do it this way, because -EINVAL can have a few
meanings, and we don't know for sure why we got it.  Could be a
bad cmd, or a bad type, or ...

If it fails, we're going to fall back anyway, so for any other
error we'd print it twice; on the fallback, we'd print the real
unexpected error anyway, so I think the user will get the relevant
information in this case.

But I guess we could do:

+       /* EINVAL is expected for XFS_GETNEXTQUOTA on older kernels */
        if (xfsquotactl(cmd, dev, type, id, (void *)&d) < 0) {
+               if (errno != ENOENT && errno != ENOSYS && errno != ESRCH &&
+                   (cmd == XFS_GETNEXTQUOTA && errno != EINVAL)

and then change what we print (not perror("XFS_GETQUOTA") in all cases)?

But if we got i.e. EPERM, we'd print the EPERM error twice; once for the
first call, and once for the fallback.  I suppose that'd be ok, but not
sure it's helpful.

-Eric

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