On Tue, 2009-02-24 at 08:42 -0500, Simo Sorce wrote: > Seth, the fact that sqlite or other db-style files have problems on some > networked filesystem either indicate a bug in the db or in such > filesystems. > > NFS(v2/3) is known to be a bad file system, sure it "mostly" works for > users, but has so many problems I do not even care to think anymore > (riduculous locking, stateless, no decent client caching ...). nfs v2/v3 are known to be filesystems in common use. They are also known to be the filesystems that worked with multiuser configurations in the past. It's not like this has been a problem for networks all along and people only suddenly realized it. When I started managing shared resource unix/linux systems a decade ago multiple logins to multiple desktops were running all the time. Hell, in many cases the end-user systems didn't even have local disks to speak of. Somehow we managed with nfsv2. > NFSv4 and CIFS should be much better, is sqlite breaks on these > filesystems there are perhaps bugs in their client kernel components. > It would be better to fix the FSs rather then just ditch the problem > completely. It might be worthwhile to ask what the features are we're getting out of moving things to sqlite, for example, before deciding that there is a problem to be fixed at all. The foregone conclusion seems to be that we have to add data-rich features. I don't think that's a good given. > That said, given home directories must stay on a trusted server anyway, > building a central daemon that the networked desktops can use instead of > trying to open databases over networked filesystems (performance sucks > when opened from multiple clients) is also a good idea. central daemons are a problem unless they are designed like filesystem infrastructure are designed: fault tolerant, capable of fail over and redundant. And configuration daemons have, in the past, been designed very poorly and/or horribly over engineered (ACAP as an example, ORBit as another). We need to NOT lock out one set of users for another set of users. -sv -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
