Matthew Wilcox wrote:
On Thu, Dec 14, 2006 at 03:00:41PM -0600, Rob Ross wrote:
I don't think that I understand what you're saying here. The openg()
call does not perform file open (not that that is necessarily even a
first-class FS operation), it simply does the lookup.
When we were naming these calls, from a POSIX consistency perspective it
seemed best to keep the "open" nomenclature. That seems to be confusing
to some. Perhaps we should rename the function "lookup" or something
similar, to help keep from giving the wrong idea?
There is a difference between the openg() and path_to_handle() approach
in that we do permission checking at openg(), and that does have
implications on how the handle might be stored and such. That's being
discussed in a separate thread.
I was just thinking about how one might implement this, when it struck
me ... how much more efficient is a kernel implementation compared to:
int openg(const char *path)
{
char *s;
do {
s = tempnam(FSROOT, ".sutoc");
link(path, s);
} while (errno == EEXIST);
mpi_broadcast(s);
sleep(10);
unlink(s);
}
and sutoc() becomes simply open(). Now you have a name that's quick to
open (if a client has the filesystem mounted, it has a handle for the
root already), has a defined lifespan, has minimal permission checking,
and doesn't require standardisation.
I suppose some cluster fs' might not support cross-directory links
(AFS is one, I think), but then, no cluster fs's support openg/sutoc.
Well at least one does :).
If a filesystem's willing to add support for these handles, it shouldn't
be too hard for them to treat files starting ".sutoc" specially, and as
efficiently as adding the openg/sutoc concept.
Adding atomic reference count updating on file metadata so that we can
have cross-directory links is not necessarily easier than supporting
openg/openfh, and supporting cross-directory links precludes certain
metadata organizations, such as the ones being used in Ceph (as I
understand it).
This also still forces all clients to read a directory and for N
permission checking operations to be performed. I don't see what the FS
could do to eliminate those operations given what you've described. Am I
missing something?
Also this looks too much like sillyrename, and that's hard to swallow...
Regards,
Rob
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
