On Tue, Mar 14, 2017 at 10:11:57AM -0400, Scott Mayhew wrote:
> On Mon, 13 Mar 2017, J. Bruce Fields wrote:
>
> > On Fri, Mar 10, 2017 at 04:46:12PM -0500, Scott Mayhew wrote:
> > > This patch adds a new config option called "cluster-mode" for sharing
> > > client records from the cltrack database between nodes of an HA cluster
> > > such as pacemaker.
> > >
> > > When enabled:
> > >
> > > 1. We have a sqlite db in a hidden directory (".nfsdcltrack") on each
> > > export.
> >
> > I'm worried about storing any nfsdcltrack in an exported filesystem.
> >
> > Access restrictions that might make sense for the rest of the export may
> > be too permissive for this stuff. We don't want a client to be able to
> > modify the database,
>
> In my test setup I have the database file writable only by root, so the
> server would have to have root squashing disabled.
Well, we do support disabling of root squashing. For some exports,
auth=sys,no_root_squash may be the most useful configuration. I'm
uncomfortable prohibiting that.
> > How does the merging work? What happens when some of the clients from
> > an export's .nfsdcltrack/ database are the same as known clients?
>
> The known clients are left as-is. That's what the 'OR IGNORE' in the
> INSERT statement in the merge function is for (the id is the primary
> key of the clients table -- the 'OR IGNORE' tells sqlite what to do in
> the event that it were to violate that constraint).
Obviously I'm putting off reading the code, apologies....
> > > 4. When client records are added (cltrack_create()), updated
> > > (cltrack_check()), or removed (cltrack_remove() and
> > > cltrace_gracedone()) from the local db, they're added/updated/removed
> > > from db on each of the exports as well.
> >
> > Could you explain why you think this will give us the correct behavior
> > across migrations and reboots?
>
> The idea was that if the export's db was kept up to date then it would
> reflect what clients were keeping their lease active with the node
> that was previously exporting the filesystem, and therefore should be
> allowed to reclaim their locks from the node that was taking over the
> export after it was moved or if the old node rebooted.
OK, thanks for the explanations!
I'd like to mull this over a bit.
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
