Re: libquota proposal

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

On Wed, Mar 23, 2011 at 03:45:34PM +0000, David Holland 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 ...

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

> 
> Shouldn't the migration be a single transparent tunefs operation?

it's hard to have it fully automated.

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

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