Re: [PATCH 0/7] clstated: add a daemon to track NFSv4 client names on stable storage (RFC)

[Steve Dickson <SteveD@redhat.com>]

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? 

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()?
> 
> 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...

steved.

steved.