Re: fs-independent quotas

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

On Tue, Nov 15, 2011 at 11:54:12AM +0100, Manuel Bouyer 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.

...and neither is acceptable for the quotactl system call, either in
the kernel processing it or in userlevel processing the returned data.
The code has to be right; consequently, what happens if it's wrong is
less important or even entirely unimportant.

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

And I still don't agree, or even really see where the substance of the
argument is.

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

That's true but each command code is associated with a specific type,
in the same way that functions are associated with a specific type.

Well, in a similar way. Is what you're objecting to here that the old
quotactl interface used void pointers and wasn't (even halfway)
typesafe? That seems like a stronger point but it has nothing
whatsoever to do with compatibility...

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

That line of reasoning can be used to justify almost any bad
architectural decision (ranging from HTML email to using msdosfs as an
application save format...) so I'm not going to accept it.

Writing language bindings for a simple and straightforward library is
a simple and straightforward undertaking.

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

That's fine, but that's not manipulating quotas on unmounted
filesystems. Or at least, not the way I was thinking of. Admittedly it
gets blurry.

IMO, operating on quota data of a filesystem is a live operation (like
operating on directory contents or whatever) and should only be
guaranteed to be supported on a mounted fs.

There is definitely value to being able to operate on an unmounted fs,
but I think this is in general the domain of sector editors and tools
like fsdb... or tools like sysutils/mtools, which we theoretically
have for all filesystems via pooka's work. My current understanding is
that quotactl is not hooked up in there, but in principle it could be
in the future.

That said, editing offline quota1 files directly could be supported
mostly transparently in libquota. However, I think it needs to be
planned out properly to avoid unwanted/unexpected behavior; certainly
things like scanning fstab for the locations of the quota files
shouldn't be done by default.

(Tangent: why isn't there such a thing as a decent sector editor for
Unix?)

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

That is definitely a bug. And it's likely to still exist. Do you have
a way to reproduce it, or to try to reproduce it? Did it affect all
tools or only some/one? (And where's the PR number? :-p )

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