Chris Samuel wrote:
> On Mon, 21 Sep 2015 07:54:55 PM Peter Ross wrote: > > > I would like to export parts of the server file systems but do not > > need to share them between the clients. So I don't need all the > > overhead of leases that expire, server-side locking etc. > > > > Instead it would be good enough to do locking on the client side and > > write a journal which can be send to the file server. > > Isn't this basically NFSv4 delegations? If you're exporting it to just a > single client then I'd expect no other client can interfere with them. > > https://www.ietf.org/rfc/rfc3530.txt > > 1.4.6. Client Caching and Delegation > [...] > > The major addition to NFS version 4 in the area of caching is the > ability of the server to delegate certain responsibilities to the > client. When the server grants a delegation for a file to a client, > the client is guaranteed certain semantics with respect to the > sharing of that file with other clients. At OPEN, the server may > provide the client either a read or write delegation for the file. > If the client is granted a read delegation, it is assured that no > other client has the ability to write to the file for the duration of > the delegation. If the client is granted a write delegation, the > client is assured that no other client has read or write access to > the file. > > Delegations can be recalled by the server. If another client > requests access to the file in such a way that the access conflicts > with the granted delegation, the server is able to notify the initial > client and recall the delegation. This requires that a callback path > exist between the server and client. If this callback path does not > exist, then delegations can not be granted. The essence of a > delegation is that it allows the client to locally service operations > such as OPEN, CLOSE, LOCK, LOCKU, READ, WRITE without immediate > interaction with the server. Yes, that sounds like it. I have to investigate how to configure this behaviour. I could not find it in the nfs(5) manpage of CentOS6 servers. Yes, Russell, I thought of iSCSI but in this case I want to make use of the server filesystem. Regards Peter On Mon, Sep 21, 2015 at 9:06 PM, Chris Samuel <[email protected]> wrote: > On Mon, 21 Sep 2015 07:54:55 PM Peter Ross wrote: > > > I would like to export parts of the server file systems but do not > > need to share them between the clients. So I don't need all the > > overhead of leases that expire, server-side locking etc. > > > > Instead it would be good enough to do locking on the client side and > > write a journal which can be send to the file server. > > Isn't this basically NFSv4 delegations? If you're exporting it to just a > single client then I'd expect no other client can interfere with them. > > https://www.ietf.org/rfc/rfc3530.txt > > 1.4.6. Client Caching and Delegation > [...] > > The major addition to NFS version 4 in the area of caching is the > ability of the server to delegate certain responsibilities to the > client. When the server grants a delegation for a file to a client, > the client is guaranteed certain semantics with respect to the > sharing of that file with other clients. At OPEN, the server may > provide the client either a read or write delegation for the file. > If the client is granted a read delegation, it is assured that no > other client has the ability to write to the file for the duration of > the delegation. If the client is granted a write delegation, the > client is assured that no other client has read or write access to > the file. > > Delegations can be recalled by the server. If another client > requests access to the file in such a way that the access conflicts > with the granted delegation, the server is able to notify the initial > client and recall the delegation. This requires that a callback path > exist between the server and client. If this callback path does not > exist, then delegations can not be granted. The essence of a > delegation is that it allows the client to locally service operations > such as OPEN, CLOSE, LOCK, LOCKU, READ, WRITE without immediate > interaction with the server. > > -- > Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC > > _______________________________________________ > luv-main mailing list > [email protected] > http://lists.luv.asn.au/listinfo/luv-main >
_______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
