On Wed, 14 Dec 2011 15:31:25 -0500 Steve Dickson <SteveD@xxxxxxxxxx> wrote: > > > On 12/14/2011 11:34 AM, Jeff Layton wrote: > > On Wed, 14 Dec 2011 11:26:00 -0500 > >>>>>>> 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? > >> > > > > Generally shouldn't be needed unless you're debugging. Today, we just > > have a bunch of directories in the v4recoverydir with md5 hash names, > > so I think moving to a DB is a step forward in this sense. > Or possible an overkill?? How large do you expect these lists > to grow? > At least one record per client. So probably on the order of a few thousand per cluster node. Multiply that times the number of cluster nodes. > Also, from what the Nfsd4_server_recovery wiki says all that is > really need is "stable storage". What makes sqlite more stable > than a simple write() followed by an fsync()? Eventually we need to share this DB in a cluster too. With that, we'll have to coordinate these writes and fsyncs across cluster nodes to ensure that they don't clobber each other. Now we have a simple write/fsync plus fcntl locking. Things get less simple... There are also atomicity concerns too. What happens if we try to write out a record and only part of it gets written out before the node dies? sqlite3 databases are journalled so that's not a problem there. The transaction just didn't happen. With flat files, you have to be able to deal with those cases on your own. Witness the growth in code that we had to maintain when Chuck moved from sqlite for new-statd to using the legacy statd flat file format. > > > > There's a sqlite3 tool that you can use to attach to the DB file(s). > > Then you can run sql commands against the tables in it. The DB layout > > at this point is very simple, so this shouldn't be too hard. > > > > Note that I'm not dead-set on using sqlite for this if there's > > something more suitable. What I really don't want to do though is to > > reinvent the wheel. Storing info safely on stable storage is a solved > > problem, IMO... > > > I took a look there does not appear to be any dependencies at all... > So that worry was unfounded... Whats another dependency?? ;-) Lets just > make sure using db is not overkill... then I'm good to go... > Again, I'm not set on sqlite. Maybe something else would be better? There's bdb for instance, and samba has the tdb stuff. I haven't looked at them in great detail but they might also work here too. I really don't have any desire to write yet another flat file storage engine for this however. -- 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
