When a process attempts to read from an empty file originating from
psshfs mount, it waits indefinitely. Until the hanged process is
interrupted, the mounted filesystem appears to work as expected,
except for the directory containing the empty file. Processes trying
to list that directory also hang, and cause misbehaviour of the
containing directory. It is possible to create a chain of hanged
processes trying to read directories up to the mount point. At the
same time, psshfs generates some network traffic (around 5KB/s, in
my case). Interrupting the first hanged process causes emission of
an error message by all other hanged processes, and psshfs ceases
to generate network traffic. Subsequent trials to list any affected
directory or if one of the affected directories is the mount point
to unmount the filesystem, fail with the same error.
This means within the cache window, a setattr that wouldn't change the
remote file's attributes from our current view of them will not be
relayed to the server and wait for the server to answer. Thus, e.g., a
process with a periodic timer interrupt that calls open(2) in a loop
can make progress with much higher probability than without caching.
XXX The test case doesn't work, so it's currently disabled. It needs
to stop the child of sshd that is handling an sftp session, not sshd
itself, and it's not obvious how to do that.
ok pooka
- The use.fs property is gone.
- Mark the tests/fs/t_create:attrs test as broken when using the default
unprivileged-user:_atf setting. This probably deserves a fix somehow
but I'm not sure at this point.
christos