[Lustre-devel] Queries regarding LDLM_ENQUEUE
Paul Nowoczynski
pauln at psc.edu
Wed Oct 20 08:16:59 PDT 2010
Yes! I think I was at this HEC meeting a few years ago?? :)
Here are the pointers to the manpages if anyone else is interested.
http://www.opengroup.org/platform/hecewg/
So my question wasn't so much about the interface which is why I posed a
scenario based on MPI. But rather, how feasible is it to import the
necessary state the from the client issuing openg() to the rest?
paul
Nicolas Williams wrote:
> On Wed, Oct 20, 2010 at 10:51:06AM -0400, Paul Nowoczynski wrote:
>
>> Eric makes a good point in that only parallel jobs really need this
>> feature. Unfortunately, at scale the system (both clients and servers)
>> *really do* need something like this, especially if we continue pushing
>> users to perform N-1 file I/O instead of 'file per process'. I too am in
>> agreement that some sort of capability mechanism is the best approach. I
>> wonder if this is something that could be done outside of POSIX and
>> supported through a parallel I/O library? Perhaps a single application
>> threads could make a special open call (/proc magic perhaps?) and obtain
>> the glob of opaque bytes which are then broadcast to the rest of the
>> client via mpi. Traversing the namespace would be avoided on all but one
>> client. In such a scenario I don't feel that enforcing unix permissions
>> at every level of the path is needed or sensible, the operation should
>> be treated as a simple logical open. The question to the lustre experts
>> - can enough state be packed into an opaque object such that the
>> recv'ing client can construct the necessary cache state?
>>
>
> POSIX already has what you're asking for, and it's called openg() ;)
>
More information about the lustre-devel
mailing list