On 1/26/16 11:52 AM, Jan Kara wrote: > On Tue 26-01-16 09:00:25, Eric Sandeen wrote: >> On 1/26/16 6:57 AM, Jan Kara wrote: >>> On Fri 22-01-16 12:25:31, Eric Sandeen wrote: >>>> Q_XGETNEXTQUOTA is exactly like Q_XGETQUOTA, except that it >>>> will return quota information for the id equal to or greater >>>> than the id requested. In other words, if the requested id has >>>> no quota, the command will return quota information for the >>>> next higher id which does have a quota set. If no higher id >>>> has an active quota, -ESRCH is returned. >>> >>> Actually, is -ESRCH the right return value? It seems XFS traditionally >>> returns -ENOENT when id doesn't exist. So that would look more logical to >>> me. >> >> Hm, I was just going by the quotactl manpage, TBH, which says: >> >> ESRCH No disc quota is found for the indicated user. >> >> >> But yes, you are right, it is ENOENT for xfs... argh. I suppose the >> quotactl manpage could use an update as well, then. > > Yeah, so VFS quotas use ESRCH when quota for particular fs is not enabled > (while ENOENT means device you passed in doesn't exist). 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... *nod* thanks. I'll just resend the XFS patches to the XFS list. -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
