On Tue, Dec 18, 2001 at 12:18:50PM -0000, David Laight wrote:
> Additionally a single VOP request into the layered fs might requst in
> many calls to the underlying fs.  The fs I have (last port was to
> unixware 7MP) supports 32 layers and will dynamically create/delete the
> top layer directories in order to create a file.  So a single VOP_INACTIVE
> call may cause any number of VOP_RMDIR operations!

[...]

> Seems to me that the sequence:
>     VOP_THROTTLE( vp, .... );
>     VOP_xyz( vp, ... );
> is not really different from:
>     VOP_xyz( vp, ... );
> 
> myfs_xyz( vp, ... ) {
>     myfs_throttle( vp, )
> 
> The latter needing no extra VOP stuff.
> What have I missed?
> 
> I guess NFS hits the VOP_xxx functions directly as well - rather that
> going through the system call code?

The NFS server code does indeed call them directly. There are a few
of VOPs that may also need throttling, but are called from inside the
bowels of the fs code, like VOP_TRUNCATE.

The NFS case poses one more problem. If the code to sleep for available
resources is inside the filesystem code itself, an nfsd may
sleep waiting for resources. This is fine for a normal process,
but an nfsd could be doing other useful things., like serving
requests for other filesystems. If you have something like VOP_THROTTLE,
you can pass it a flag saying "don't sleep, just report EAGAIN", at
which point you can requeue the request (making sure you don't
get starvation of course), and serve some other requests.

Now, you could make all VOPs just return EAGAIN (or a similar error)
in case of resource shortage. But then you have to teach all of
the fs code to deal with that. That would be a big problem.

> Yes - but something needs to tell the softdeps code that it better
> release some of its resources (or is it always doing it as fast as
> it can?).  The process it does the releasing doesn't have to be the
> one that made the request - indeed, as you said, that isn't a good
> place to try.

The problem is, even if you tell the syncer to get rid of dependencies
as fast as it can, there is still no guarantee that there isn't a process
that is adding requests more quickly than they can be pushed out
to disk. This is the basic problem that I'm trying to address here.

- Frank
-- 
Frank van der Linden                           fvdl@wasabisystems.com
======================================================================
Quality NetBSD CDs, Support & Service.   http://www.wasabisystems.com/