[V9fs-developer] v9fs Questions

[Eric V. H. <er...@gm...>]

Ron, I'm going to start just using the developer's list on sourceforge
so there's some sort of record of these things for posterity.

So, it looks like I had the 2.6 v9fs working, but there are several
things I've run into - some of them I've "fixed".  Some are things
that should be options in the future.

First of all, t_wstat seemed like it was horribly broken from a
'chown' standpoint.  I'm not sure if this ever worked with u9fs
because there's not much of a concept of chown from Plan 9 - so I
fixed it.  Also,  I went ahead and did UNIX semantics for file
creation (the person who creates the file owns the file versus whoever
is running u9fs or whoever attaches).  This is something that is
definately worth making an option in the future, but this seems to be
the correct behavior.  I also set default flags for noatime,
nodiratime, and synchonous
writes.  The first two don't match plan 9 semantics well (so they
should be options) but
dramatically reduce t_write traffic.  The synchronous writes may
impact performance but are closer to plan 9 behavior.

Another bit which seems badly broken (maybe this only happens on 2.6)
- is cacheing of fids.  Basically after a long u9fs run, when I
finally unmount, I see almost ever fid ever used get clunked. 
Fundamentally, when I cat a file, it never gets clunked.  I assume
this is probably due to the dcache holding onto the inode associated
with the fid.  I'm currently delving into this, but the changes I'm
thinking of have pretty broad implications, so I wanted to bounce them
off of you before I started down the path.

Essentially, fid's are transient transactions.  The only time fids
stay open are the attach fid and a fid for an open file.  In practice
(at least in 2.6) it seems fids are almost always kept open (I see
clunks on removes, and on directory listings, but otherwise I don't
see any).  Also, during lookups, v9fs is cloneing the fid at every
step of the hierarchy (and then holding the fid open).  While this may
not impact passive file systems, this could have nasty implications
for synthetics.

My intent is to match (as closely as possible) the same transactions
that I see from a real plan 9 system.  What this will mean:
   a) all operations will clone from the attach fid, and then walk to
their destination using that single cloned fid.
   b) fid's get clunked unless the file is open (all sorts of
interesting problems implementing this - may have to rework large
sections of the code to get the semantics right)

At the root of the issue is the cacheing of fids for lookups.   This
stuff is being kept around the dcache and generally making life
miserable.

In principal as long as it is used single user and nobody else is
touching the same files as you everything is fine, but when there are
multiple writers stuff starts to screw up.  Also, I think the symlink
stuff may break things like "cd ..", but I'm punting on
testing/debugging the symlink stuff until I get other stuff working.

    -eric