[Gluster-devel] handling statfs call in USS

[Raghavendra Bhat]

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
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.

Regards,
Raghavendra Bhat

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