Re: [nfsv4] Issue 21: pnfs EOF handling

Benny Halevy wrote:
> Garth Goodson wrote:
> 
>>
>>
>> Benny Halevy wrote:
>>
>>> Black_David@emc.com wrote:
>>>
>>>> The simplest fix may be to only issue CB_SIZECHANGED for an explicit
>>>> SETATTR,
>>>> and never for any implicit EOF change (write or commit).  A more
>>>> comprehensive
>>>> approach would be to add a "why" flag to CB_SIZECHANGED to distinguish
>>>> implicit extension from explicit length set, although I can't 
>>>> immediately
>>>> figure out why a pNFS client needs to see an implicit EOF change for 
>>>> file
>>>> extension. 
>>>
>>>
>>>
>>>
>>> [snip]
>>>
>>> David, In the objects case, when the file is striped over multiple 
>>> objects and the
>>> client gets a read beyond its notion of the EOF it has to go read 
>>> from storage
>>> to determine the current file length or issue a GETATTR to the MDS.
>>> If the file is holey and was sparsely written by another client 
>>> beyond this client's
>>> notion of the EOF it is possible that the client will get a short 
>>> read from one
>>> of the objects but there's more data in higher offsets on other objects.
>>> In order to make this data visible the client needs to know the new EOF.
>>>
>>> Benny
>>>
>>
>> Same for files.  Alternatively, extending writes could extend the 
>> files on the data servers.
> 
> 
> This has a similar race between writers since the SETATTR operation 
> would need an "extend only"
> flag to make sure nobody else's data is being truncated.
> 

I was thinking it could be implemented by the backend protocol, which as 
you say, would have to have some way of serializing writes and truncates...

-Garth

>>
>> -Garth
>>
>>>
>>> _______________________________________________
>>> nfsv4 mailing list
>>> nfsv4@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/nfsv4
>>
>>
> 

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4