Thanks Dan for the reply -- Jiffin On 24/09/15 18:21, Daniel Gryniewicz wrote: > A layout is a guarantee of ownership for the portion of the file > covered. No other conflicting file access can be done while the > layout is granted. So, if conflicting access is needed, the layout > must be recalled. In addition, if something happens in the cluster > that would invalidate that access to that part of the file (such as > loss of a node moving data to a backup node, or cluster optimization > moving the location of the data, or storage nodes partitioning making > the data unavailable, etc.), the layout must be recalled. > > It's probably best to recall layouts via an upcall. VFS is not the > best model to follow here, since it's not a clustered filesystem. > > Dan > > On Thu, Sep 24, 2015 at 5:07 AM, Jiffin Tony Thottan > <jthot...@redhat.com> wrote: >> Hi all, >> >> Currently I am trying to add support for LAYOUTRECALL in FSAL_GLUSTER. >> So I look through other >> FSAL implementation and RFC5661 once again. As far as I understand it is >> a notification send from >> M.D.S. to client demanding back the layouts. First I try to figure out >> scenarios in which layoutrecall >> is useful and following came into my mind(May be I am wrong and also >> please help me finding more) : >> >> 1.) While an I/O is performed , layout of file changes due to a >> gluster-internal process >> >> 2.) two clients performing I/O on same file based on layout provided by >> two different M.D.Ses >> [Currently in FSAL_GLUSTER provides layout for entire file because >> entire file is located on Storage Device] >> >> 3.) When detach a brick from the storage pool in gluster. >> >> But as a second thought , is it necessary to have LAYOUTRECALL ? Layout >> grants permission to a client >> for performing a I/O. But it does not guarantee such that only `this >> client can perform I/O on that`. >> And commenting out LAYOUTRECALL from FSAL_CEPH increases my doubt. >> >> And one more question , FSAL_GPFS introduced LAYOUTRECALL as part of >> UPCALL thread and FSAL_VFS >> as part of a call back thread. So which one will be better should >> handled as part of UPCALL thread or >> separately using another thread ? >> >> Please correct me if anything mentioned above is wrong. >> >> With Regards and Thanks, >> Jiffin >> >> ------------------------------------------------------------------------------ >> Monitor Your Dynamic Infrastructure at Any Scale With Datadog! >> Get real-time metrics from all of your servers, apps and tools >> in one place. >> SourceForge users - Click here to start your Free Trial of Datadog now! >> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 >> _______________________________________________ >> Nfs-ganesha-devel mailing list >> Nfs-ganesha-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel > ------------------------------------------------------------------------------ > Monitor Your Dynamic Infrastructure at Any Scale With Datadog! > Get real-time metrics from all of your servers, apps and tools > in one place. > SourceForge users - Click here to start your Free Trial of Datadog now! > http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 > _______________________________________________ > Nfs-ganesha-devel mailing list > Nfs-ganesha-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
------------------------------------------------------------------------------ _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
