Date: Thu, 10 Jan 2013 13:09:00 +0200 From: Andrey Simonenko <simon@comsys.ntu-kpi.kiev.ua> To: Jason Keltz <jas@cse.yorku.ca> Cc: FreeBSD Filesystems <freebsd-fs@freebsd.org> Subject: Re: Problems Re-Starting mountd Message-ID: <20130110110900.GA1419@pm513-1.comsys.ntu-kpi.kiev.ua> In-Reply-To: <50EDB8B9.4030507@cse.yorku.ca> References: <50EC39A8.3070108@cse.yorku.ca> <972459831.1800222.1357690721032.JavaMail.root@erie.cs.uoguelph.ca> <20130109135703.GB1574@pm513-1.comsys.ntu-kpi.kiev.ua> <50EDB8B9.4030507@cse.yorku.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 09, 2013 at 01:36:41PM -0500, Jason Keltz wrote: > On 01/09/2013 08:57 AM, Andrey Simonenko wrote: > > > > I did not check delay in NFSE code for NFS clients during updating of > > NFS export settings, but it will be less than time used by nfse, since > > NFSE code in the NFS server uses deferred data releasing and it require > > to acquire small number of locks. Two locks are acquire while all NFS > > export settings are updated, one lock is acquire for transaction and one > > lock is acquire for each passed security flavor list and credentials > > specification. Each security flavor list and credential specification or > > any specification is passed in own command, so if there are ~2000 file > > systems exported to the same address specification, then corresponding > > security flavor list and credential specification are passed only one time. > Thanks for all of the helpful information on nfse. > In all fairness, I didn't know what nfse was initially, so I read about > it here: > http://sourceforge.net/projects/nfse/ > (Given the maintainer, Andrey, I can see why you're such an expert in > nfse!) :) > > Will it work under 9.1? or is it still development? I try to keep changes for etc/, cddl/ and sys/ in sync with CURRENT and check everything on CURRENT. Backports of changes for FreeBSD 8.2 (RELEASE) and 9.1 (recent STABLE) source code are here: http://nfse.sourceforge.net/8.2/ http://nfse.sourceforge.net/9.1/ Most recent backport of NFSE for 8.2 and 9.1 should work with most recent nfse utility for CURRENT. NFSE code can be considered as development since NFSE API can be changed, its configuration file format nfse.conf(5) can be changed, I do not have any information whether somebody verified correctness of sys/fs/nfsserver/nfs_export.c code and verified the idea of NFS exports support in NFS server (not in VFS as it is implemented now, as a side effect ZFS snapshots are not automatically exported by NFSE). > Since nfse doesn't use nmount() call (is this correct?), I get the > impression that whether it processes the entire export configuration (I > realize custom to nfse) or not, I assume that we wouldn't see any delay > when using ZFS? If some implementation build NFS export settings, then change a single pointer to this data and then use some kind of garbage collector to free previous settings, then there will be no delay. Both mountd and nfse introduce some delay, since NFS export settings are updated and exclusive lock is required to protect these settings. Amount of this delay is different because different approaches are used, amount of delay from nmount() came from ZFS code as I understand. Also NFS export settings should be updated atomically, under atomic update I understand atomic update of all NFS export settings for all pathnames. The nfse utility work with own nfse.conf(5) configuration and also it understands exports(5) format. More information about the compatibility mode can be read on http://nfse.sourceforge.net/ site. Dynamic updates work only if nfse.conf(5) format is used. By the way there are changes for zfs in cddl.diff that allow to use dynamic updates for 'zfs set sharenfs' commands. > Would the solution then be to use nfse or do I still > need to wait for it to be stable when maybe 10.0 is released? I cannot answer this question. > > Maybe without thinking this through too much, since nfse is newer, it > would be interesting if there was an option for a "living" "exports" > file. With a standard exports file, if you update it live, the changes > aren't reprocessed until issuing a command, and then everything is > unexported and reexported. What if you could change the exports file on > the fly, nfse sees that the file has changed, compares what is in the > file to the current exported state, and then acts accordingly to sync > the two states by adding or deleting exports... of course, if processing > the whole file takes such a short time, maybe this doesn't make any > sense.... (and of course if you run out of space and truncate the file > accidentally..whoops..) I considered such approach and it will not work because of logic of dynamic changes. Dynamic changes like "nfse -c 'add /fs ...'" change NFS export settings on-the-fly, they are not change settings in any file and are not saved on nfse exit (something like changing firewall settings from the command line). When old and new configuration diff is found, it is unclear how it can be applied to the current configuration, since this diff can be denied because of previous applied dynamic updates. Also if a user keeps configuration in several files, then it is impossible to get diffs from all changed files at one time (these diffs will be sequential) and this can introduce security problem, since partial update can allow export to not allowed hosts. I think that automatic support of directories with configuration files will simplify configuration management and will allow controlable and fast updates of NFS export settings. More advanced update logic is possible with nfse commands as well. If somebody has interest in nfse, then it can be run on 8.x, 9.x and 10.x without any modification to existent FreeBSD sources and on systems with working mountd. Just apply below given patch to force it to not call nfssvc(NFSSVC_EXPORT), use TESTING-BUILD from NFSE archive to build it and use the following switches to not register a server for the MOUNT protocol: # nfse -dl -m no It will report different errors, because nfssvc(NFSSVC_EXPORT) was not really called, but it will allow to test it and its logic (I suggest to read nfse(8) and nfse.conf(5) if a new configuration is used and do not forget to run "nfse -et" or "nfse -t" to check configurations or commands). --- nfse.c.orig 2013-01-09 12:26:25.000000000 +0200 +++ nfse.c 2013-01-10 12:45:49.000000000 +0200 @@ -269,6 +269,7 @@ port_resv(in_port_t port) static int nfsserver_call(struct nfse_cmds_hdr *hdr) { +return (0); if (nfssvc(NFSSVC_EXPORT, hdr) == 0) return (EXPCMD_RET_OK);
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130110110900.GA1419>