On Monday 29 December 2014 01:19 PM, RAGHAVENDRA TALUR wrote:
On Sun, Dec 28, 2014 at 5:03 PM, Vijay Bellur <vbellur@xxxxxxxxxx> 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@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
