On Wed, 05 Aug 2009 19:30:04 -0400 Trond Myklebust <trond.myklebust@xxxxxxxxxx> wrote: > On Wed, 2009-08-05 at 18:24 -0400, Chuck Lever wrote: > > On Aug 5, 2009, at 5:22 PM, Trond Myklebust wrote: > > > On Wed, 2009-08-05 at 14:26 -0400, Chuck Lever wrote: > > >> sqlite3 doesn't do anything special under the covers. It uses only > > >> POSIX file access and locking calls, as far as I know. So I think > > >> hosting /var on most well-behaved clustering file systems won't have > > >> any problem with this arrangement. > > > > > > So we're basically introducing a dependency on a completely new > > > library > > > that will have to be added to boot partitions/nfsroot/etc, and we have > > > no real reason for doing it other than because we want to move from > > > using sync() to fsync()? > > > > > > Sounds like a NACK to me... > > > > Which library are you talking about, libsqlite3 or libtirpc? Because > > NEITHER of those is in /lib. > > libsqlite is the problem. Unlike libtirpc, it's utility has yet to be > established. > Sorry to revive this so late, but I think we need to come to some sort of resolution here. The only missing piece for client side IPv6 support is statd... I'm not sure I understand the objection to using libsqlite3 here. We certainly could roll our own routines to handle data storage, but why would we want to do so? sqlite3 is quite good at what it does. Why wouldn't we want to use it? > > In any event, it's not just sync(2) that is a problem. sync(2) by > > itself is a boot performance problem, but it's the combination of > > rename and sync that is known to be especially unreliable during > > system crashes. Statd, being a crash monitor, shouldn't depend on > > rename/sync to maintain persistent data in the face of system > > instability. I'd call that a real reason to use something more robust. > > What are you talking about? Is this about the truncate + rename issue > leaving empty files upon a crash? > That issue is solved trivially by doing an fsync() before you rename the > file. That entire discussion was about whether or not existing > applications should be _required_ to do this kind of POSIX pedantry, > when previously they could get away without it. > > IOW: that issue alone does not justify replacing the current simple file > based scheme. > There are other reasons, not to use the simple file-based scheme too... Internationalized domain names will be easier to deal with via sqlite3, for instance. Certainly we could code this up ourselves, but what's the benefit to doing that when we have a perfectly good data storage engine available? -- 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
