Stackable file systems and NFS

[Ranjan Sinha]

Hi,

On Tue, Aug 14, 2012 at 4:19 PM, Rajat Sharma <fs.rajat at gmail.com> wrote:
> Try mounting with noac nfs mount option to disable attribute caching.
>
> ac / noac
>
> "Selects whether the client may cache file attributes. If neither
> option is specified (or if ac is specified), the client caches file
> attributes."

i don't think this is because of attribute caching. The size does change and
that is why we go to the read call (think of this is a simplified case of
tail -f). The only problem is that sometimes when we read we get ASCII NUL bytes
at the end. If we read the same block again, we get the correct data.

In addition, we cannot force specific mount options in actual deployment
scenarios.


<edit>

>> On Tue, Aug 14, 2012 at 5:10 PM, Ranjan Sinha <rnjn.sinha at gmail.com> wrote:
>> > For now, /etc/export file has the following setting
>> > *(rw,sync,no_root_squash)
>>
>> hm, AFAIK that means synchronous method is selected. So,
>> theoritically, if there is no further data, the other end of NFS
>> should just wait.
>>
>> Are you using blocking or non blocking read, btw? Sorry, i am not
>> really that good reading VFS code...
>>

This is a blocking read call. I think this is not because there is no data,
rather somehow the updated data is not present in the VM buffers but the
inode size has changed. As I just said, if we read the file again from the
exact same location, we get the actual contents. Though after going through the
code I don't understand how is this possible.

>> > On client side we have not specified any options explicitly. This is
>> > from /proc/mounts entry
>> > >rw,vers=3,rsize=32768,wsize=32768,hard,proto=tcp,timeo=600,retrans=2,sec=sys
>>
>> hm, not sure, maybe in your case, read and write buffer should be
>> reduced so any new data should be transmitted ASAP. I was inspired by
>> bufferbloat handling, but maybe I am wrong here somewhere....
>>

-- 
Regards,
Ranjan