On 2011-04-05 12:48, Trond Myklebust wrote: > On Tue, 2011-04-05 at 12:11 -0700, Benny Halevy wrote: >> On 2011-04-05 10:14, Garth Gibson wrote: >>> The OpenGroup HECE proposals for extending the application/filesystem interface did not have a team of implementers behind them. At the time some of the parallel file system vendors that added modules to the kernel were willing to work toward supporting these interfaces, but not a broader community. >>> >>> I encourage the pNFS community to consider the use cases that led to those proposals. >>> >>> One example is lazy attributes. Folks running large parallel jobs have a nasty habit of monitoring the progress of the job by running on their desktop a looping script doing ls -l on output files. What is the length of a file that is open and being written to by other nodes? Much of the time you want to be able to ask for a recently accurate value of attributes without recalling layouts, but perhaps some of the time you would like layouts to be recalled, or at least committed. >> >> Right now the pNFS server does not have to recall the layout on GETATTR >> so lazy would be the default behavior for most implementations. Even if >> a client holds a delegation the server could send a CB_GETATTR to it to >> get the latest attributes without recalling the layout. At any rate, >> the broader issue is that the posix system call API assumes a local file >> system and is not network not cluster file-system aware. > > Recalling the outstanding layouts in a directory on every 'ls -l' sounds > like the perfect recipe for poor performance. I can't see why any > servers would want to do this. > > In any case, a layout recall does not trigger client writeback: layouts > do not define a caching protocol. Yet for already written (DATA_SYNC) data, a layout recall should trigger a LAYOUTCOMMIT and that will update the visible attrs. Benny > > Trond -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
