Re: fs-independent quotas

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

On Thu, Oct 20, 2011 at 03:47:26PM +0000, David Holland wrote:
> On Thu, Oct 20, 2011 at 05:23:14PM +0200, Manuel Bouyer wrote:
>  > > That's way more complicated than necessary. Think of it as like
>  > > VOP_READDIR - you get passed a position, you send back some number of
>  > > items, and update the position.
>  > 
>  > Depending on how the data are stored on disk, the notion of position
>  > (which also implies some ordering) can be difficult to handle,
>  > especially if the data we're reading can change between two calls,
>  > causing the position do become invalid.
> 
> ...yes, but this is just one of those things you have to cope with
> when doing filesystems. It's no different from readdir in that regard.
> 
>  > It's certainly less trouble to send back to userland the whole set of
>  > data - especially if what userland wants is the whole set of data
>  > (I can't see what a partial read of quota would be usefull for).
> 
> No, no it really isn't. Suppose there are, say, 50,000 users, so to
> send back the whole works you have to accumulate 100,000 quota entries
> in a gigantic blob... a machine with 50,000 users will have enough RAM
> for this but that doesn't mean that allocating a contiguous chunk of
> kernel memory that large is easy or desirable. Far better to read it
> out a couple hundred at a time.

We're talking a few MB of ram here, isn't it ? the kernel can certainly
allocate this without troubles (other subsystems do).


> 
> There are two design truisms for database stuff that apply here:
> first, you always end up wanting cursors, and second, you always end
> up wanting bulk get (and not just single get) from those cursors. So
> it's usually a good idea to anticipate this and design it all in up
> front.

Maybe ... I know that in the end I want the whole set of data and not
just a part of it. But if you believe it's needed this can
easily be added to the existing quotactl(2) (it would just be a new command).

> 
>  > > The reason to wrap the position in a cursor abstraction is to allow
>  > > flexibility about how the position is represented.
>  > 
>  > But then the cursor would still be stored in userland ?
> 
> That's the idea, like reading a file with pread().
> 
> I think the kernel should know, or at least be able to know, how many
> cursors are currently open; but I don't think there's any need to keep
> the cursor state itself in the kernel.

So you want a quotaopen/quotaclose, with a file descriptor (or something
similar) ?

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