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.
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.
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.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
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
