Re: fs-independent quotas

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

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.

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.

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

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