On Tue, Jan 6, 2015 at 12:43 PM, Raghavendra Bhat <rabhat@xxxxxxxxxx> wrote: > 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 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@xxxxxxxxxxx >>> http://www.gluster.org/mailman/listinfo/gluster-devel >> >> >> > -- Raghavendra Talur _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
