On 12/5/06, Rob Ross <rross@mcs.anl.gov> wrote:
quoted text
> Hi,
>
> I agree that it is not feasible to add new system calls every time
> somebody has a problem, and we don't take adding system calls lightly.
> However, in this case we're talking about an entire *community* of
> people (high-end computing), not just one or two people. Of course it
> may still be the case that that community is not important enough to
> justify the addition of system calls; that's obviously not my call to make!

I have the feeling that openg stuff is rushed without looking into all
solutions, that don't require changes to the current interface. I
don't see any numbers showing where exactly the time is spent? Is
opening too slow because of the number of requests that the file
server suddently has to respond to? Does having an operation that
looks up multiple names instead of a single name good enough? How much
time is spent on opening the file once you have resolved the name?

quoted text
> I'm sure that you meant more than just to rename openg() to lookup(),
> but I don't understand what you are proposing. We still need a second
> call to take the results of the lookup (by whatever name) and convert
> that into a file descriptor. That's all the openfh() (previously named
> sutoc()) is for.

The idea is that lookup doesn't open the file, just does to name
resolution. The actual opening is done by openfh (or whatever you call
it next :). I don't think it is a good idea to introduce another way
of addressing files on the file system at all, but if you still decide
to do it, it makes more sense to separate the name resolution from the
operations (at the moment only open operation, but who knows what'll
somebody think of next;) you want to do on the file.

quoted text
> I think the subject line might be a little misleading; we're not just
> talking about NFS here. There are a number of different file systems
> that might benefit from these enhancements (e.g. GPFS, Lustre, PVFS,
> PanFS, etc.).

I think that the main problem is that all these file systems resove a
path name, one directory at a time bringing the server to its knees by
the huge amount of requests. I would like to see what the performance
is if you a) cache the last few hundred lookups on the server side,
and b) modify VFS and the file systems to support multi-name lookups.
Just assume for a moment that there is no any way to get these new
operations in (which is probaly going to be true anyway :). What other
solutions can you think of? :)

Thanks,
    Lucho
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html