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 rump kernel just attaches to / in said rump kernel instance.
This is mostly useful in case wanting to see what nodes components
create (see Makefile).
not built without manual intervention
without the directory timeout expiring, we get vattr_null as the
attributes for that file. Ensure that we always report sane
attributes by getting them from the server if this is the case.
(also, sprinkle some const)
Fixes problem reported by dyoung. But wait! The bug's medallion
begins to glow! The bug looks much better! I crumble to dust.
There's probably another similar bug related to "lazy open". It
will trigger if we reclaim a node before the response to the open
arrives. Even the comments (typoless) know about this bug ...
But verifying it exists and fixing it will have to wait for another
day.
may not apply to this particular server.
TODO: have three different texts, one for device backed file systems
(e.g. ffs), another for network backed (e.g. nfs), and a third for
fictional (e.g. kernfs)
Don't build & install it by default, since it represents the state
of the rump virtual kernel and not the host kernel. However, it's
useful for debugging kernfs.
Instead of copulating with newfs to produce a new FFS image into
memory, mmap() a given existing image and pass that as the backing
store. If -s is given, mmap is done with MAP_SHARED and changes
are kept across mounts, else MAP_COPY (i.e. MAP_PRIVATE for us) is
done and changes are lost when the server exits.
Note: -s does not guarantee any kind of file system safety whatsoever
and in case of kill, crash, exit or other form of elusion,
everything will be, according to our theme, quite screwed.
after readdir is called for the root dir the first time (yes,
there's still a window of wrong link count after the fs is mounted.
it's currently quite difficult to call sftp_readdir() from outside
the main loop).
Should fix "find /mnt" problem for a mountpoint with more than the
"guessed" amount of subdirectories, as reported by dyoung.
riastradh