All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Jan Kara <jack@suse.cz>
Cc: linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [PATCH 2/7] quota: add new quotactl Q_XGETNEXTQUOTA
Date: Tue, 26 Jan 2016 12:39:59 -0600	[thread overview]
Message-ID: <56A7BD7F.6010802@redhat.com> (raw)
In-Reply-To: <20160126175205.GA29388@quack.suse.cz>

On 1/26/16 11:52 AM, Jan Kara wrote:

> Yeah, so VFS quotas use ESRCH when quota for particular fs is not enabled
> (while ENOENT means device you passed in doesn't exist).

And what does it return for "that ID has no quota?"  Anything?  Maybe not,
see below?

> So probably a
> solution that keeps XFS and VFS interfaces most selfconsistent is to return
> ENOENT from Q_XGETNEXTQUOTA and ESRCH from Q_GETNEXTQUOTA. I'll update your
> patches in this sense in the comments and changelogs. But XFS patches
> (which I don't carry) need updating the actual code...

Actually, ok, now I'm a little more confused.

Today, Q_XGETQUOTA and Q_GETQUOTA will both return -ENOENT on XFS if a
quota doesn't exist for that ID:

quotactl(Q_GETQUOTA|USRQUOTA, "/dev/sdb2", 123456789, 0x7ffdf2edbc80) = -1 ENOENT (No such file or directory)
quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sdb2", 123456789, 0x7ffdf2edbc10) = -1 ENOENT (No such file or directory)

It seems like the *NEXT* variants (on xfs at least?) may as well continue to do the same...

But on ext4, I see 0 returned for a nonexistent quota:

quotactl(Q_GETQUOTA|USRQUOTA, "/dev/sdb1", 123456789, {bhardlimit=0, bsoftlimit=0, curspace=0, ihardlimit=0, isoftlimit=0, curinodes=0, ...}) = 0
quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sdb1", 123456789, {version=1, flags=XFS_USER_QUOTA, fieldmask=0, id=123456789, blk_hardlimit=0, blk_softlimit=0, ino_hardlimit=0, ino_softlimit=0, bcount=0, icount=0, ...}) = 0

So the difference doesn't seem to be XGETQUOTA vs GETQUOTA, rather it's the filesystem handling the call?

Still, we do need a way to pass back "No more quotas to find" from Q_[X]GETNEXTQUOTA; XFS will do -ENOENT, but if -ENOENT and -ESRCH already have specific meanings on non-xfs filesystems, I'm not sure where we go from there.

Sorry for my confusion.  :(

-Eric

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

WARNING: multiple messages have this Message-ID (diff)
From: Eric Sandeen <sandeen@redhat.com>
To: Jan Kara <jack@suse.cz>
Cc: linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [PATCH 2/7] quota: add new quotactl Q_XGETNEXTQUOTA
Date: Tue, 26 Jan 2016 12:39:59 -0600	[thread overview]
Message-ID: <56A7BD7F.6010802@redhat.com> (raw)
In-Reply-To: <20160126175205.GA29388@quack.suse.cz>

On 1/26/16 11:52 AM, Jan Kara wrote:

> Yeah, so VFS quotas use ESRCH when quota for particular fs is not enabled
> (while ENOENT means device you passed in doesn't exist).

And what does it return for "that ID has no quota?"  Anything?  Maybe not,
see below?

> So probably a
> solution that keeps XFS and VFS interfaces most selfconsistent is to return
> ENOENT from Q_XGETNEXTQUOTA and ESRCH from Q_GETNEXTQUOTA. I'll update your
> patches in this sense in the comments and changelogs. But XFS patches
> (which I don't carry) need updating the actual code...

Actually, ok, now I'm a little more confused.

Today, Q_XGETQUOTA and Q_GETQUOTA will both return -ENOENT on XFS if a
quota doesn't exist for that ID:

quotactl(Q_GETQUOTA|USRQUOTA, "/dev/sdb2", 123456789, 0x7ffdf2edbc80) = -1 ENOENT (No such file or directory)
quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sdb2", 123456789, 0x7ffdf2edbc10) = -1 ENOENT (No such file or directory)

It seems like the *NEXT* variants (on xfs at least?) may as well continue to do the same...

But on ext4, I see 0 returned for a nonexistent quota:

quotactl(Q_GETQUOTA|USRQUOTA, "/dev/sdb1", 123456789, {bhardlimit=0, bsoftlimit=0, curspace=0, ihardlimit=0, isoftlimit=0, curinodes=0, ...}) = 0
quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sdb1", 123456789, {version=1, flags=XFS_USER_QUOTA, fieldmask=0, id=123456789, blk_hardlimit=0, blk_softlimit=0, ino_hardlimit=0, ino_softlimit=0, bcount=0, icount=0, ...}) = 0

So the difference doesn't seem to be XGETQUOTA vs GETQUOTA, rather it's the filesystem handling the call?

Still, we do need a way to pass back "No more quotas to find" from Q_[X]GETNEXTQUOTA; XFS will do -ENOENT, but if -ENOENT and -ESRCH already have specific meanings on non-xfs filesystems, I'm not sure where we go from there.

Sorry for my confusion.  :(

-Eric

  parent reply	other threads:[~2016-01-26 18:40 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-22 18:25 [PATCH 0/7 V3] quota: add new quotactl Q_GETNEXTQUOTA Eric Sandeen
2016-01-22 18:25 ` Eric Sandeen
2016-01-22 18:25 ` [PATCH 1/7] quota: remove unused cmd argument from quota_quotaon() Eric Sandeen
2016-01-22 18:25   ` Eric Sandeen
2016-01-25 14:47   ` Jan Kara
2016-01-25 14:47     ` Jan Kara
2016-01-25 14:49     ` Jan Kara
2016-01-25 14:49       ` Jan Kara
2016-01-22 18:25 ` [PATCH 2/7] quota: add new quotactl Q_XGETNEXTQUOTA Eric Sandeen
2016-01-22 18:25   ` Eric Sandeen
2016-01-25 14:51   ` Jan Kara
2016-01-25 14:51     ` Jan Kara
2016-01-26 12:57   ` Jan Kara
2016-01-26 12:57     ` Jan Kara
2016-01-26 15:00     ` Eric Sandeen
2016-01-26 15:00       ` Eric Sandeen
2016-01-26 17:52       ` Jan Kara
2016-01-26 17:52         ` Jan Kara
2016-01-26 17:57         ` Eric Sandeen
2016-01-26 17:57           ` Eric Sandeen
2016-01-26 18:39         ` Eric Sandeen [this message]
2016-01-26 18:39           ` Eric Sandeen
2016-01-26 20:40           ` Jan Kara
2016-01-26 20:40             ` Jan Kara
2016-01-22 18:25 ` [PATCH 3/7] quota: add new quotactl Q_GETNEXTQUOTA Eric Sandeen
2016-01-22 18:25   ` Eric Sandeen
2016-01-25 14:51   ` Jan Kara
2016-01-25 14:51     ` Jan Kara
2016-01-22 18:25 ` [PATCH 4/7] xfs: don't overflow quota ID when initializing dqblk Eric Sandeen
2016-01-22 18:25   ` Eric Sandeen
2016-01-22 18:25 ` [PATCH 5/7] xfs: get quota inode from mp & flags rather than dqp Eric Sandeen
2016-01-22 18:25   ` Eric Sandeen
2016-01-22 18:25 ` [PATCH 6/7] xfs: Factor xfs_seek_hole_data into helper Eric Sandeen
2016-01-22 18:25   ` Eric Sandeen
2016-01-22 18:25 ` [PATCH 7/7] xfs: wire up Q_XGETNEXTQUOTA / get_nextdqblk Eric Sandeen
2016-01-22 18:25   ` Eric Sandeen
2016-01-26 18:40   ` [PATCH 7/7 V4] " Eric Sandeen
2016-01-26 18:40     ` Eric Sandeen
2016-01-25 15:07 ` [PATCH 0/7 V3] quota: add new quotactl Q_GETNEXTQUOTA Jan Kara
2016-01-25 15:07   ` Jan Kara
2016-01-25 16:04   ` Eric Sandeen
2016-01-25 16:04     ` Eric Sandeen
2016-01-26 13:10 ` Jan Kara
2016-01-26 13:10   ` Jan Kara
  -- strict thread matches above, loose matches on Subject: below --
2016-01-22  4:07 [PATCH 0/7 V2] " Eric Sandeen
2016-01-22  4:07 ` [PATCH 2/7] quota: add new quotactl Q_XGETNEXTQUOTA Eric Sandeen
2016-01-22  4:07   ` Eric Sandeen
2016-01-22  8:55   ` Jan Kara
2016-01-22  8:55     ` Jan Kara
2016-01-22 13:57     ` Eric Sandeen
2016-01-22 13:57       ` 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=56A7BD7F.6010802@redhat.com \
    --to=sandeen@redhat.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.