On Wed, 14 Dec 2011 10:44:27 -0500 Steve Dickson <SteveD@xxxxxxxxxx> wrote: > > > On 12/14/2011 10:32 AM, Jeff Layton wrote: > > On Wed, 14 Dec 2011 10:23:15 -0500 > > Steve Dickson <SteveD@xxxxxxxxxx> wrote: > > > >> > >> > >> On 12/14/2011 08:57 AM, Jeff Layton wrote: > >>> This patchset is the userspace portion of the knfsd client name tracking > >>> overhaul. See this patch series for an explanation: > >>> > >>> nfsd: overhaul the client name tracking code (RFC) > >>> > >>> The daemon listens for upcalls on the rpc_pipefs pipe using libevent, > >>> and handles the requests. > >>> > >>> The data is stored using a sqlite database. The main reason for this is > >>> that it takes care of most of the fussy details and atomicity concerns > >>> of tracking the information on stable storage. > >> This will make nfs-utils dependent on the sqlite database... Any idea > >> what kinda of extra baggage this brings? > >> > > > > Depends on what you mean by "baggage". What is your concern? > In Fedora doing a 'yum install sqlite' which would require > a ton of other package needing to be install... The Required > for nfs-utils is getting pretty long at this point... > I don't think it pulls in that much. This is pretty minimal for dependencies: $ ldd /usr/lib/libsqlite3.so.0.8.6 linux-gate.so.1 => (0x00e05000) libdl.so.2 => /lib/libdl.so.2 (0x001bd000) libpthread.so.0 => /lib/libpthread.so.0 (0x00769000) libc.so.6 => /lib/libc.so.6 (0x00e27000) /lib/ld-linux.so.2 (0x4e572000) I think the command-line tools have some dependency on ncurses and readline and such, but I don't think it's that much really... In any case, perhaps it's time to split the nfs-utils packaging for fedora into client and server pieces? Clients really only need a few of the tools, but they can't install that on fedora without getting all of the server pieces too. That's a separate discussion though... > > > > For something like fedora, it'll mean a build-time dependency on > > sqlite-devel, and a runtime dependency on sqlite. We could consider > > embedding their single-file amalgamation code, but I'd prefer not to do > > that unless we really have to. > > > >>> > >>> For now, the daemon is only suitable for single-host configurations. > >>> The plan is to later extend this to be suitable for clustered > >>> configurations as well. > >>> > >>> The code is still a little rough, so be gentle. It also lacks things > >>> like a manpage. I plan to add all that before doing a "formal" patch > >>> submission, but I wanted to get some early review of the overall design > >>> before to spend a lot of time knocking off the rough edges. > >> Finally the name of the daemon... clstated does not make it clear that > >> this is a nfs server daemon... maybe something like nfsdcld? > >> > > > > Sure, we could change the name if that's desirable. Maybe > > nfsd.clnamed ? At this point it's really just a client name tracking > > daemon. > How about nfsdcld ;-) short, to the point and easy to type... 8-) > Ok, I'm not religious on this issue. I'll plan to rename it to that. -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
