On Wed, Aug 05, 2009 at 02:05:44PM -0400, Chuck Lever wrote: > On Aug 5, 2009, at 1:48 PM, J. Bruce Fields wrote: >> On Wed, Aug 05, 2009 at 10:45:40AM -0400, Chuck Lever wrote: >>> Provide a new implementation of statd that supports IPv6. The new >>> statd implementation resides under >>> >>> utils/new-statd/ >>> >>> The contents of this directory are built if --enable-tirpc is set >>> on the ./configure command line, and sqlite3 is available on the >>> build system. Otherwise, the legacy version of statd, which still >>> resides under utils/statd/, is built. >>> >>> The goals of this re-write are: >>> >>> o Support IPv6 networking >>> >>> Support interoperation with TI-RPC-based NSM implementations. >>> Transport Independent RPC, or TI-RPC, provides IPv6 network support >>> for Linux's NSM implementation. >>> >>> To support TI-RPC, open code to construct RPC requests in socket >>> buffers and then schedule them has been replaced with standard >>> library calls. >>> >>> o Support notification via TCP >>> >>> As a secondary benefit of using TI-RPC library calls, reboot >>> notifications and NLM callbacks can now be sent via connection- >>> oriented transport protocols. >>> >>> Note that lockd does not (yet) tell statd what transport protocol >>> to use when sending reboot notifications. statd/sm-notify will >>> continue to use UDP for the time being. >>> >>> o Use an embedded database for storing on-disk callback data >>> >>> This whole exercise is for the purpose of crash robustness. There >>> are well-known deficiencies with simple create/rename/unlink >>> disk storage schemes during system crashes. Replace the current >>> flat-file monitor list mechanism which uses sync(2) with sqlite3, >>> which uses fsync(3). >> >> If someone wants to move around that data, is it still simple to do >> that? (Where is it kept on the filesystem?) >> >> (I'm thinking of someone that shares it for high-availabity, as in: >> >> http://www.howtoforge.com/high_availability_nfs_drbd_heartbeat_p3 >> >> Or maybe somebody that just needs to move their /var partition to a >> different disk one day.) > > Statd's monitor lists and state number are stored in a single regular > file, /var/lib/nfs/statd/statdb by default. This file can be easily > backed up, or used on other systems, if desired. I would recommend > ensuring the NSM state number is reset in the latter case, which can be > done with the sqlite3 command. > > I've had some dialog with Lon Hohberger about clustering requirements. I > think we are looking at crafting a separate utility that uses sqlite3 C > function calls to extract data that's interesting to the clustering > implementation. Again, this could even be scripted with bash and the > sqlite3 command, but perhaps a C program is more maintainable. OK, good. And for the simplest cases, it should still be enough to just copy /var/lib/nfs/, right? --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
