Re: libquota proposal

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

On Wed, Mar 23, 2011 at 05:10:08PM +0100, Manuel Bouyer wrote:
 > > > > No, it doesn't. Even before you touched anything, they were only
 > > > > scribbling directly as a fallback if the kernel operations failed.
 > > > > The kernel operations should not fail in any case where scribbling
 > > > > directly makes sense; furthermore there's no need at all to deal with
 > > > > the case where the fs isn't mounted.
 > > > 
 > > > repquota at last needs them: it doesn't have any way to get a list
 > > > of quotas otherwise
 > > 
 > > That sounds like a bug.
 > 
 > it's the way it works now ~forever ...

Yes, but wasn't one of the purposes of using plists to make that
possible?

And if not, it should have been regardless, as the interface to quotas
needs to be fs- and format-independent.

 > >  > (and it's also part of the migration to quota2,
 > >  > with repquota -x).
 > > 
 > > ...wait, we're exposing the plists directly to the user?
 > 
 > yes of course. that's one of the points of using plists, isn't it ?

...no, I wouldn't say so. Things the user is meant to look at it
shouldn't generally be plists, as plists weren't ever meant to be
human-readable and aren't very; meanwhile, things that are meant to be
fed to shell scripts are much better off being tables.

 > right now I have a perl script which parses repquota output, with all the
 > bugs/misfunctions this implies, and then calls edquota.  With the plist
 > interface, I can have my perl script parse plists instead, and generate
 > plists to send to the kernel.

That 

 > > Shouldn't the migration be a single transparent tunefs operation?
 > 
 > it's hard to have it fully automated.

er, why?

 > >  > > In the new world order all userland quota operations go through the
 > >  > > kernel interface so they can interact successfully with filesystems
 > >  > > using either the old or new quota layouts, or with new filesystems
 > >  > > that may have their own different quota layouts, like zfs or whatever
 > >  > > else. Right?
 > >  > 
 > >  > right. Exept that the "getall" command is not supported for quota1,
 > >  > repquota does the job itself.
 > > 
 > > uh, why not? that *is* a bug.
 > 
 > because to get the whole set of quota with quota1, you have to read
 > all of the (potentially sparse) quota file (it can be up to 128GB
 > if you use uid -1).  I don't want to do this in the kernel ...

Much better to do it from inside the FS, where you can pretty easily
skip over nonmaterialized blocks, than to violate modularity and
abstraction boundaries so you can stream all 128GB of zeros to
userland.

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