Re: fs-independent quotas

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

On Mon, Nov 14, 2011 at 01:48:17PM +0000, David Holland wrote:
>  > > 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;

An error is still better than a crash.

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

And I still think a text-based format is better than a binary format for
backward compatibility.

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

Or when you send different commands which takes different arguments,
which is the case for the quota syscall and VNOPS.
> 
>  > > 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.

So you propose to remplace something that we can work with using existing
modules it various language, by something that needs a specific module (to
be written) for each langage. Clearly that's not a win.

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

that's exactly the case I'm in: quotas files in /var/quotas, quotas enabled on
other filesystems and not /var.

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

I dropped this functionnality for ufs-quota2; I used it for ufs-quota1
because otherwise things would go wrong (something to do with offsets:
a uid would get the quotas for another uid - of course this is a bug, but
I never managed to track it down).

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