[Lustre-devel] Queries regarding LDLM_ENQUEUE

[Andreas Dilger]

Note that I was in contact with the HECEWG also, and openg() was proposed to be renamed to be more understandable. 

The current Linux name_to_handle() proposal could be used to export an blob identifier (file handle that holds a FID, fs UUID, and a cookie/capability in the Lustre case) to userspace, then MPI-IO or some other mechanism can be used to distribute this to other client processes and open_by_handle() to convert this back into a file handle. 

One question is whether mpi_open() could be used for a collective operation (allowing this to be handled inside the Lustre ADIO layer) or if it would need specific application support?

Cheers, Andreas

On 2010-10-20, at 9:16, Paul Nowoczynski <pauln at psc.edu> wrote:

> 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() ;)
>> 
> 
> _______________________________________________
> Lustre-devel mailing list
> Lustre-devel at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-devel