On Tue, 2009-02-24 at 09:11 -0500, seth vidal wrote: > 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. oh but it has, ever tried to do locking on nfsv2/3 ? No? Wonder why most apps have been working around proper locking inventing abominations like lockfiles and other 1000 non standard and all incompatible ways to mange locking because it was always broken on NFS ? To the point that now 99% of unix apps don't even acknowledge nor test for locks on files and die hard is locks are mandatory or just completely ignore them if they are advisory (making advisory locking almost useless). > 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. Yes, when I started a decade ago I had similar setups, I am *not* advocating breaking networked home directories, but boy, we have to stop making up systems that sucks only because people *insist* on using a broken network filesystem. > Somehow we managed with nfsv2. yes, *somehow* I managed too and it was bitter hate. Isn't it time to fix our stuff to work well and not "somehow" ? It's not like we can't change protols today. Back then the NFS server was an old Unix machine, with proprietary software we could not touch, today we have Linux servers, I think we can fix stuff, and *surprise*, we have NFSv4 and CIFS that do a *much* better job at serving out files with decent semantics. > > 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. As you well know some apps will use (and do use, like Firefox, evolution, ..) sqlite already, it's late to ask if it is good or not, its time to fix whatever need fixing if they do not work with NFSv4/CIFS. > The foregone conclusion seems to be that we have to add data-rich > features. I don't think that's a good given. Make a better proposal, but just screaming: "this breaks on broken NFSv3!!" does not seem like anything useful to me, sorry. > > 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). Sure, there are requirements to be met, you think I'd advocate for broken daemons after ranting about broken filesystems ? However they do not need to be more fault tolerant than current filesystems where you put your home on. > We need to NOT lock out one set of users for another set of users. No, we should not, in either direction. Simo. -- Simo Sorce * Red Hat, Inc * New York -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
