Re: fs-independent quotas

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

On Sat, Oct 29, 2011 at 05:14:30PM +0000, David Holland wrote:
> [...]
>    3. Abolish the proplib-based transport encoding. Since it turns out
>       that the use of proplib for quotactl(2) is only to encode struct
>       ufs_quota_entry for transport across the user/kernel boundary,
>       converting it back on the other side, it seems to me that it's
>       a completely pointless complication and a poor use of proplib.
>       It's also messy, even compared to other proplib usage elsewhere.
>       (Regarding claims of easier/better compatibility, see below.)

Ho no, not again !

The arguments that ufs_quota_entry (or whatever its name is) will
be good enough for any future filesystem is just not true. We already
have been in this argument.

> 
>    4. Abolish the xmlrpc-type user interface of quotactl(8) in favor
>       of something else saner and easier to work with.

work with with *what* ?

> 
> 3. There's already been some discussion of the compat issues in this
> thread. Basically it boils down to: if you send a program material
> that it's not expecting to receive, it won't be able to cope with it
> and will fail/die/crash. This is true whether the material is binary
> or a proplib bundle or text or whatever else.

With a binary it'll probably crash. With a text-based format it will notice
the syntax error return an error code. This is a big difference,
especially for kernel.

> 
> 4. If using split on the output of quota/repquota/whatnot isn't good
> enough (in some specific places we may want a machine-readable-output
> option) then the best way to access the quota system from Perl or
> Python (or Ruby or Lua or ...) is with a set of bindings for the new
> proposed libquota. This should be straightforward to set up once the
> new libquota is in place. I think the current quotactl(8) should just

Are you going to provide those bindings ? I'm interested in perl.

> be dropped. Among other things, I've been told that XML-based user
> interfaces are specifically prohibited by act of Core.

I'd like an official word from core on this. I don't remmeber seeing
this stated anywhere.

> - As far as I can tell there is not and never has been support for
> manipulating quotas on unmounted filesystems.

There was in quoya(1), repquota(8) and edquota(8), and I've been using
it with netbsd-5. Just read the code in the netbsd-5 branch to see it.

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