Re: A filesystem philosophy question

[larz@world.std.com (Mike A Larson) writes:]

>> If, in fact,
>> both files are in the same filesystem, I guess you could trim off everything
>> except the filesystem-relative part and pass that. But this doesn't seem
>> like a very good solution. ...
>Why isn't this a very good solution for intra-filesystem renames (ie,
>renames within the same filesystem partition or name space)? As a matter
>of fact, why isn't this the best solution for the case where both
>the source and destination files reside in the same directory (eg,
>mv foo bar) and the rename consists of simply changing the file's
>directory name entry(s)?

Recall that the path lookup loop is not encoded in the server. Why add
an entire new mechanism to servers to solve an edge case?

But this *has* brought to mind an issue I hadn't considered. What to
do about filesystems where there is a many->one relationship of directory
entries to files? You'd either have to record the path in the open file
state (talk about new mechanism) or something equally expensive.

Hmmm... if we *did* pass two filesystem-relative paths, and I *did* add
the code to deal with this, then there's another optimization I've been
pondering which fits with this:

In the current system, I use the Plan9 technique of walking the pathname one
element at a time. But once you walk *into* a VSTa filesystem, you'll never
walk back out--so why not pass all that path into the server and save the
cost of the context switches needed for each element traversal? The code
needed to deal with these paths for a rename() is pretty much the same code
needed to implement this optimization. Interesting....

Oh, and since we're rambling around this morning, another optimization.
I notice that many filesystems encode some file state in the directory
structure. So for directory traversal tools, the needed information
may be available to them simply for the cost of walking the directory.
However, the UNIX architecture ignores this, with the result that you have
to actually stat() the file to hear anything about it.

What I've been thinking is that the FS_READ of a directory should perhaps
be allowed to pass back extra information which it has available anyway.
So currently an FS_READ of a directory gets:

entry1
entry2
entry3

and instead a filesystem would be allowed to pass back "freebies":

entry1 type=f size=1234 atime=6463537 mtime=6463433
...

Of course, this is useless to POSIX utilities, but I'm thinking that
it might still be worth it to optimize the case of ls, and perhaps a
couple others. In the common case (ls -CF, for instance) you would never
have to do that extra FS_STAT message to pick up the file type.

                                                Andy
Received on Thu Mar 10 09:51:44 1994