repeated open system calls do not cause repeated open messages

[GoogleCodeExporter]

  wget http://swtch.com/fusetest-0.4.tar.gz  # also attached
  tar xzvf fusetest-0.4.tar.gz
  cd fusetest-0.4
  make
  ./fusetest -D simple /mnt
  ./open /mnt/f read read
  ./open /mnt/f write write

Fusetest is a simple fuse file server that, when run in simple mode,
presents a single file /mnt/f.  It ignores setattr requests but allows them
to succeed.  Running with -D prints the fuse traffic prefixed by FUSE:.  
Running ./open /mnt/f read read (or write write) executes open("/mnt/f",
O_RDONLY (or O_WRONLY)) twice.

The expected output from fusetest when running ./open /mnt/f read read is
two Open messages, but fusetest sees only one:

Here is Linux output (the "read: 3" and "read: 4" lines are the output from
./open):

linux# ./open /mnt/f read read
    FUSE -> len 2 unique 0x7  Lookup nodeid 0x1 name 'f'
    FUSE <- unique 0x7 (Lookup) nodeid 0x3 gen 0x2 ...
    FUSE -> len 8 unique 0x8  Forget nodeid 0x3 nlookup 1
    FUSE -> len 2 unique 0x9  Lookup nodeid 0x1 name 'f'
    FUSE <- unique 0x9 (Lookup) nodeid 0x3 gen 0x3 ...
    FUSE -> len 8 unique 0xa  Open nodeid 0x3 flags 0x8000 mode 0
    FUSE <- unique 0xa (Open) fh 0x4 flags 0x1
read: 3
    FUSE -> len 8 unique 0xb  Open nodeid 0x3 flags 0x8000 mode 0
    FUSE <- unique 0xb (Open) fh 0x5 flags 0x1
read: 4
    FUSE -> len 16 unique 0xc  Flush nodeid 0x3 fh 0x4 flags 0
    FUSE <- unique 0xc (Flush)
    FUSE -> len 16 unique 0xd  Release nodeid 0x3 fh 0x4 flags 0x8000
    FUSE <- unique 0xd (Release)
    FUSE -> len 16 unique 0xe  Flush nodeid 0x3 fh 0x5 flags 0
    FUSE <- unique 0xe (Flush)
    FUSE -> len 16 unique 0xf  Release nodeid 0x3 fh 0x5 flags 0x8000
    FUSE <- unique 0xf (Release)
linux# 

Notice that there are two Open messages.

mac# ./open /mnt/f read read
    FUSE -> len 8 unique 0  Access nodeid 0x1 mask 0x1
    FUSE <- unique 0 (Access)
    FUSE -> len 2 unique 0x1  Lookup nodeid 0x1 name 'f'
    FUSE <- unique 0x1 (Lookup) nodeid 0x7 gen 0x2 ...
    FUSE -> len 8 unique 0  Access nodeid 0x7 mask 0x4
    FUSE <- unique 0 (Access)
    FUSE -> len 8 unique 0x1  Open nodeid 0x7 flags 0 mode 0
    FUSE <- unique 0x1 (Open) fh 0x8 flags 0x1
read: 3
    FUSE -> len 8 unique 0  Access nodeid 0x7 mask 0x4
    FUSE <- unique 0 (Access)
read: 4
    FUSE -> len 24 unique 0x1  Release nodeid 0x7 fh 0x8 flags 0
    FUSE <- unique 0x1 (Release)
mac# 

Notice that there is only one Open message.
There should be two (and two Releases).

The story is the same with Write (just one, should be two).

One of the great things about FUSE as compared with user-level NFS is that
servers get to see all the file operations. 
Please don't hide them.

I am using MacFUSE 0.2.2.

Original issue reported on code.google.com by russ...@gmail.com on 27 Mar 2007 at 1:19

Attachments:

• fusetest-0.4.tar.gz

[GoogleCodeExporter]

> "Please don't hide them."

Well.

The fact that you don't see every single open message is an unfortunate aspect 
of the MacFUSE 
implementation. It's working "as designed".

In the MacFUSE vnop_open (vnode-level open) function, I don't have access to 
the file descriptor that is being 
used for the open. Similarly, in vnop_close, I don't have access to the file 
descriptor. Throw in opens that 
might be required from other code paths (such as the strategy routine, which 
would need file handles 
asynchronously), and the situation is worse. Given what the Mac OS X kernel 
lets a VFS kernel extension do, it 
isn't possible to correlate the opens and closes based on the most appropriate 
thing: the file descriptor. The 
current MacFUSE compromise is to reuse file handles (with reference counting). 
This means you will not see all 
opens go through to user-space, because if they did go to user-space, MacFUSE 
wouldn't know what to do 
with the file handle user space would generate for each open.

Original comment by si...@gmail.com on 28 Mar 2007 at 12:37

[GoogleCodeExporter]

Marking this as "WontFix" because this is a known architectural side effect.

Original comment by si...@gmail.com on 28 Mar 2007 at 3:12

• Changed state: WontFix