On 12/14/2011 11:05 AM, Jeff Layton wrote: > 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. Yeah I thinking this is quickly becoming slippery slope... In the end I'm all for looking into using dbs instead of flat files but I'm just worrying about the size of nfs-utils footprint... Maybe unnecessarily Question, how would admin look at the list of client? Will that even be needed? >>>>> 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. > Thanks! steved. -- 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
