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.
> 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.
> Can we try to be a little more constructive, please? Asking the list
> (which includes distributors, who actually have to worry about such
> things) whether this would be a problem is significantly less abrasive
> then just saying "NACK" outright.
It would be constructive if you could actually _justify_ these
backward-incompatible changes instead of hand waving, and accusing
others of being obstructionist.
Trond
--
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
