Re: FS KPI vnop_blockmap
Re: FS KPI vnop_blockmap
- Subject: Re: FS KPI vnop_blockmap
- From: Terry Lambert <email@hidden>
- Date: Fri, 17 Mar 2006 14:30:44 -0800
On Mar 17, 2006, at 1:54 PM, Ron Aldrich wrote:
Is it legal for a filesystem's blockmap vnode operation to be called
for a file which hasn't been opened? I'm working on some
optimizations, and need to know whether I should return an error in
this case, or just handle it silently.
If your FS has vended a vp, then your FS must honor operations on that
vp until the vp has been vrele's (the vended vp reference is returned
to the FS normally) or the vp has been deadfs'ed (e.g. by a forced
unmount or other operation, in which case it's not your FS's vnode any
more).
Some FS's like to pretend that this isn't an issue for them, and that
the FS's idea of "open" and the VFS layer's idea of open must somehow
be congruent. An example of this is SMB client, which likes to have
the file "open" on the server in order to be able to read it.
In the case of execve(), we use namei() to get the FS to vend a vp for
a path, and then explicitly map/read pages out of the vp, without ever
implementing a formal open notification to the FS.
There are several good reasons for permitting this type of access; in
particular, for intermittent access, the open/close operations can be
implied. This allows an FS that's handicapped (e.g. like SMB, which
is incapable of deleting an open file) to more closely echo the
expected UNIX FS semantics.
The alternative to this would be to return ETXTBSY (for example) on
executable files on FS's where the operations could not be
accomplished - IFF the FS was notifid that an executing file was in
fact "open" from the FS's perspective.
This is problematic, since it would mean that some FS's would exhibit
the error code, while other FS's would not exhibit the error code. To
accomplish this, there would have to be a specific way of internally
marking a vnode. Further, this would constitute a KPI change, since
it's impossible to update existing programs that expect to be able to
delete/rename open files.
Even more problematic is that updates of running systems could no
longer be accomplished, if this was made a requirement, or made
universal to all FS's by implementing it without a KPI change at the
VFS layer (consider trying to update "tar" while you are using "tar"
to extract the new "tar" from a tar archive, or attempting to update
"launchd" without killing "launchd" and effectively shutting down the
OS to do it, etc.).
The inability to rename/replace/delete running programs is one of the
reasons why installing software on Windows requires a system reboot,
and why, if you hit <esc> to get the text console, instead of things
being hidden behind the splash screen, you see autoexec.bat
effectively running a postinstall script in single user mode before
the system comes back up (.bat files are tokenized into memory by
command.com, so they are immune from this requirement: they are
treated as cached data).
So in general, you will want to honor all vnop requests on vnodes
vended by your FS implementation to avoid behaving differently from
other FS's, or damaging the expected UNIX FS semantics, except where
absolutely necessary due to FS design limitations.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden