I think I have a simple solution.  It's not the most efficient, but it's
very simple.

When you unlink the file and nobody has it open, _but_ somebody has one
of the file's streams open, what should happen?

The file should not go away until the last user of all streams has gone
away.

Now, simply unlinking the file will have no effect as usual except to
reduce the file's i_nlink count.

The file will continue to exist until its i_count field reaches zero.
You must arrange for that to happen when everone has closed the file,
all its streams, and no processes have a current directory in there.

If there's a process with a dentry for one of the streams that hasn't
yet opened the stream inode, then because each dentry requires its
parent to exist and the parent dentry is guaranteed to be a positive one
with an inode reference, i_count will always be non-zero in that case.

That means you don't have to worry about dentries that are in the
process of being filled in.  Just inodes that are in use.

Now, the i_count field counts child dentries too.  But you want to
arrange that if none of the child inodes are in use, and the parent's
inode usage counting children in use but not child dentries (in use or
not -- previous paragraph explains) reaches zero, then all child
dentries should be dropped.

There's one really easy way to do that: Add a put_inode method to your
parent inode.  Have that method d_invalidate all the inodes's dentries
(follow the i_dentry list).  That will nuke all the unused child
dentries, which will release the inode if nobody is using it.

When you are using streams, it does more work than necessary sometimes,
but it should work.

A more refined solution would track usage counts and not nuke the child
dentries unless there was no "uncached" user of the parent inode.  But
that's not supported by the VFS yet.

Note: I am interested in pseudo-directories for "userfs" type purposes.
Interesting stuff.  But perhaps we need a lock-correctness proving
program before hitting this stuff too heavily :-)

-- Jamie

Reply via email to