Re: fs-independent quotas

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sun, Nov 13, 2011 at 10:36:55PM +0100, Manuel Bouyer wrote:
 > 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.

Yes, and your hypothetical examples haven't come close to convincing
me. And I agree there's no point thrashing back and forth any further;
this is why I've asked core to decide.

 > > 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.

Neither is good enough if you're providing backwards compatibility; it
has to *work*. This is the standard we're committed to, and I continue
to think there's no particular advantage for proplib in this regard,
particularly for this particular kind of data.

(I don't think any semistructured or "self-describing" data model,
including the perfect one I'd replace proplib with if I could wave a
wand to do so, provides any particular advantage for procedure call
compatibility. Sure, you can tag data bundles with version codes and
such, but we can and do already do that by tagging the call itself and
have lots of support architecture in place for doing it that way. The
advantages appear when you're dealing with irregularly structured
material, like when there are large numbers of optional fields or
optional parameters and so forth.)

 > > 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.

I don't do Perl. I might be persuaded to do Python bindings, but it
would probably be more effective to enlist someone who already knows
how to do this and won't therefore make newbie mistakes with the
interpreter. Anyway, the hard part is making the library interface
available; wrapping Perl or Python around it should be entirely
trivial.

 > > - 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.

I've looked. I don't know what you're seeing, but all I see is code
for directly manipulating the quota files. There's no logic for
mounting anything to reach them. So it'll work if the quota files are
on / and the volume is for /home regardless of whether /home is
mounted... but only because it doesn't have to touch /home in this
case.

I don't think that feature is worth preserving either, since it's
purely a side-effect of having visible quota files. And I don't see
the point; it's not like mounting the volume to run edquota will cause
a catastrophe.

-- 
David A. Holland
dholland%netbsd.org@localhost