Jeff Johnson wrote:
> 
> On Jul 31, 2007, at 6:39 PM, Mark Hatle wrote:
> 
>> Thomas Lotterer wrote:
>>> On Tuesday, 31. July 2007 at 3:04 pm, Jeff Johnson wrote:
>>>> On Jul 31, 2007, at 5:02 AM, Thomas Lotterer wrote:
>>>>> On Monday, 30. July 2007 at 9:26 pm, Jeff Johnson wrote:
>>>>>> On Jul 30, 2007, at 2:58 PM, Thomas Lotterer wrote:
>>>>>>> Decision:
>>>>>>> - exclusively use Berkeley DB
>>>>>>     3) NFS support
>>>>>>
>>>>> This can be rewritten to "networked filesystem support". BDB, SQLite
>>>>> and any embedded DB require proper filesystem locking. Given the
>>>>> environmental issues of a networked filesystem this will never work
>>>>> reliably.
>>>>>
>>>> I don't disagree. However, an answer for client/server rpmdb needs to
>>>> be identified.
>>>>
>>> No use case for client/server rpmdb has been brought to my attention.
>>
>> You have a chassis w/ 8 blades.  1 blade acts as an internal server for
>> the other 7 blades.  It serves a kernel and filesystem to the other 7.
>>
>> The other 7 blades boot and have to do things related to the rpm
>> database.  Over NFS the blades can blow up.. using RPC they will be able
>> to manipulate the database as necessary.
>>
>> That is a very common usage scenario in the Telecommunication space.  7
>> blades do the work, 1 (or 2) blades act as a control infrastructure.
>>
> 
> And in the telco space one often desires 5 9's behavior.
> 
> I'm not sure that NFS write's qualify. Try NFS to multiple clients, then
> random removes/writes on clients of  those files. The server than has
> multiple
> copies of files with identical paths, but differing per-client content.
> That's
> the NFS behavior I remember, not looked or cared for years.

There are other shared filesystem (think Fibre channel) that don't rely
on NFS.. but can't use NPTL locking because they're done on separate
machines.

I certainly don't endorse NFS for 5 9's.  :)

> Putting an rpmdb on NFS, with associated write's and rpm --rebuilddb
> behavior, is likely to cause unexpected problems. And rpmdb database
> problems are far more likely to be noticed than random write corruption
> for, say, log files or backup's.
> 
> I've also debug'ed a handful of problems with rpm installing onto large
> NFS trees, some that were quite reproducible. The last problem I remember
> was at NCSU quite a while ago, should be in bugzilla.
> 
> I doubt NFS has gotten significantly better since I last looked.

I'm pretty sure it hasn't.. :P

--Mark