Re: fs-independent quotas

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

On Thu, Oct 20, 2011 at 04:53:53PM +0200, Manuel Bouyer wrote:
 > > You don't need to track state in the kernel, you just need to keep a
 > > generation ID. Have the caller pass a "starting index" and
 > > "requested count" parameter, and have the kernel include "number of
 > > matches", "total matches", and "generation ID" in the response. Let
 > > the kernel limit the maximum number of matches to return per request
 > > if you like. If the generation ID changes while the caller is
 > > fetching records you simply restart the process.
 > 
 > I still don't see how it's going to work in details. Either
 > the kernel have to restart reading all quotas on each call to
 > return requested range, or it has to cache the previous read
 > of all quotas.
 > Once the kernel has read all the quotas, it can as well return
 > all the data to the caller, and let the caller deal with the
 > iteration.

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.

If you want to take the trouble to guarantee strict transactional
consistency, you can easily enough by checking generation numbers and
failing with a particular errno if things have changed; but I don't
think there's any real need for that level of strict consistency for
quotas. Much less so than for readdir, at least, and we manage to cope
with readdir the way it is.

The reason to wrap the position in a cursor abstraction is to allow
flexibility about how the position is represented.

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