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 <bou...@antioche.eu.org> NetBSD: 26 ans d'experience feront toujours la difference --