Re: fs-independent quotas

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Fri, Oct 21, 2011 at 08:25:44AM +0000, David Holland wrote:
> On Wed, Oct 19, 2011 at 06:09:27PM +0000, David Holland wrote:
>  > So, a few months back we got a new improved quota format for FFS.
>  > [...]
> 
> All right, I give up. Apparently the commandment Thou Shalt Not
> Question the use of the Holy Proplib is more important to the
> community than sanity, cleanliness, or long-term compatibility.
> I am not interested in pursuing this if all I'm going to get is
> complaints that I'm going on some kind of anti-proplib jihad.
> 
> The following tidbits may be of use to the person who ends up having
> to clean this up in the future:
> 
>  - the type "struct ufs_quota_entry" is apparently, despite its name
> and (parts of) its usage pattern, meant to be fs-independent.

true. More precisely it describes the traditionnal quota properties
we have seen on unix filesystems for some time (ufs is unix filesystems,
isn't it ?)

> 
>  - the recommended method for adding quotas to a new file system type
> (with its own physical quota representation) appears to be to first
> convert to struct ufs_quota_entry in the kernel, then call the
> quotaprop code to convert to a proplist for transport, which will then
> be converted back to struct ufs_quota_entry in userland.

true.

> 
>  - while some of the common userlevel quota code is in libquota, a lot
> of it is placed in various quota utilities' source directories and
> .PATH'd in from elsewhere. Some of the source files involved are not
> used by the utility they're apparently part of, so don't remove
> "unused" code without doing a full build. Some of this code is also
> cut and pasted.

true. Some of this is because of history, some because I did not completely
rewrite the tools.

> 
>  - some but not all of the libquota code is shared with the kernel and
> lives in src/common. So do some header files, even though by standard
> procedures the shared header files should live in src/sys/sys.

I don't think so. There's prior art, I'm not the one who created
common/include/. 

> However, other shared quota code is .PATH'd in from the kernel.

AFAIK no. What's .PATH'd from the kernel is code that deal with
on-disk format, like other FS tools do (fsck_ffs, dumpfs, etc ...).

> 
>  - the way the current quotactl(8) works, which is not all that clear
> from the documentation, is that you cons up an XML proplist blob
> containing XML-encoded function calls as described (sketchily) in
> quotactl(2) and feed this to quotactl(8) either as a file or on
> stdin. This allows issuing an arbitrary number of arbitrary quota
> operations in a single big packet, as interpreted and executed by the
> proplist code in the kernel. This is now the recommended/endorsed way
> to do quota operations from scripts.

No, it's not the recommended/endorsed way. It is *one* way. You can
of course keep using quota(1), edquota(8) and repquota(8) from
scripts. This is one of the things that stopped me doing too much changes
to the quota tools: if the text format used by these tools is changed,
this will break existing scripts.
Ultimately these tools shouldn't even have an internal binary representation
of quotas, the output should be driven directly by the proplist.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--