[Gluster-devel] handling statfs call in USS

[RAGHAVENDRA TALUR]

On Tue, Jan 6, 2015 at 12:43 PM, Raghavendra Bhat <rabhat at redhat.com> wrote:
> On Monday 29 December 2014 01:19 PM, RAGHAVENDRA TALUR wrote:
>>
>> On Sun, Dec 28, 2014 at 5:03 PM, Vijay Bellur <vbellur at redhat.com> wrote:
>>>
>>> On 12/24/2014 02:30 PM, Raghavendra Bhat wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I have a doubt. In user serviceable snapshots as of now statfs call is
>>>> not implemented. There are 2 ways how statfs can be handled.
>>>>
>>>> 1) Whenever snapview-client xlator gets statfs call on a path that
>>>> belongs to snapshot world, it can send the
>>>> statfs call to the main volume itself, with the path and the inode being
>>>> set to the root of the main volume.
>>>>
>>>> OR
>>>>
>>>> 2) It can redirect the call to the snapshot world (the snapshot demon
>>>> which talks to all the snapshots of that particular volume) and send
>>>> back the reply that it has obtained.
>>>>
>>> Each entry in .snaps can be thought of as a specially mounted read-only
>>> filesystem and doing a statfs in such a filesystem should generate
>>> statistics associated with that. So approach 2. seems more appropriate.
>>
>> I agree with Vijay here. Treating each entry in .snaps as a specially
>> mounted
>> read-only filesystem will be required to send proper error codes to Samba.
>
>
> Yeah makes sense. But one challenge is if someone does statfs on .snaps
> directory itself, then
> what should be done? Because .snaps is a virtual directory. I can think of 2
> ways
> 1) Make snapview-server xlator return 0s when it receives statfs on .snaps
> so that the o/p is similar the one that is obtained when statfs is done on
> /proc

I think some applications may require info from statfs like file
system block size
before they proceed with operations. May not be a hard requirement.

> OR if the above o/p is not right,
> 2) If statfs comes on .snaps, then wind the call to regular volume itself.
> Anything beyond .snaps will be sent to the snapshot world.

I see one problem with wind that Samba would expect to see a read-only flag
set for statfs result of .snaps too; otherwise a delete of .snaps in
windows explorer
would give a weird behaviour.


>
> Regards,
> Raghavendra Bhat
>
>
>>> -Vijay
>>>
>>> _______________________________________________
>>> Gluster-devel mailing list
>>> Gluster-devel at gluster.org
>>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>
>>
>>
>



-- 
Raghavendra Talur