Re: NFSv4/pNFS possible POSIX I/O API standards

[Rob Ross <rross@mcs.anl.gov>]

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'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.

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.).

Finally, your comment on making filesystem developers miserable is sort 
of a point of philosophical debate for me. I personally find myself 
miserable trying to extract performance given the very small amount of 
information passing through the existing POSIX calls. The additional 
information passing through these new calls will make it much easier to 
obtain performance without correctly guessing what the user might 
actually be up to. While they do mean more work in the short term, they 
should also mean a more straight-forward path to performance for 
cluster/parallel file systems.

Thanks for the input. Does this help explain why we don't think we can 
just work under the existing calls?

Rob

Latchesar Ionkov wrote:
> Hi,
> 
> One general remark: I don't think it is feasible to add new system
> calls every time somebody has a problem. Usually there are (may be not
> that good) solutions that don't require big changes and work well
> enough. "Let's change the interface and make the life of many
> filesystem developers miserable, because they have to worry about
> 3-4-5 more operations" is not the easiest solution in the long run.
> 
> On 12/1/06, Rob Ross <rross@mcs.anl.gov> wrote:
>> Hi all,
>>
>> The use model for openg() and openfh() (renamed sutoc()) is n processes
>> spread across a large cluster simultaneously opening a file. The
>> challenge is to avoid to the greatest extent possible incurring O(n) FS
>> interactions. To do that we need to allow actions of one process to be
>> reused by other processes on other OS instances.
>>
>> The openg() call allows one process to perform name resolution, which is
>> often the most expensive part of this use model. Because permission
> 
> If the name resolution is the most expensive part, why not implement
> just the name lookup part and call it "lookup" instead of "openg". Or
> even better, make NFS to resolve multiple names with a single request.
> If the NFS server caches the last few name lookups, the responses from
> the other nodes will be fast, and you will get your file descriptor
> with two instead of the proposed one request. The performance could be
> just good enough without introducing any new functions and file
> handles.
> 
> Thanks,
>    Lucho