[Lustre-devel] statahead feature

[Alex Zhuravlev <Alex.Zhuravlev@Sun.COM>]

Ragnar Kj?rstad wrote:
> On Thu, Jul 24, 2008 at 9:41 PM, Alex Zhuravlev <Alex.Zhuravlev@sun.com> wrote:
>> no, I don't think we need lock always: you just did getattr and fill inode
>> with fresh attributes, then you release lock, somebody changes attributes
>> on the server and only then userspace application gets attributes (already
>> non-fresh). so, what lock gives you in this case?
> 
> If I have an application that does:
> 1. Update stat data on one node.
> 2. Barrier
> 3. Read the same stat data on a different node
> 
> I should be guaranteed to get the correct data, right?
> So stat should return data that was valid either when the system call
> started, when it ended, or somewhere in between. (not data that was
> invalid even before the systemcall started)

indeed. we can't use this trick in all the cases. I think it's a subject
of discussion what we consider a barrier, for regular stat(2) it can be
start of system call. for ls -l case it can be open(2). isn't this a
reasonable cost for significant performance improvement of ls -l ?

my understanding is that for NFS with readdir+ support, the barrier will
be open(2).

thanks for this good point, Alex