[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: FSFS nosync

From: Peter Samuelson <peter_at_p12n.org>
Date: Fri, 16 Dec 2011 11:02:03 -0600

[Stefan Sperling]
> On Thu, Dec 15, 2011 at 04:04:13PM -0600, Peter Samuelson wrote:
> > http://packages.debian.org/sid/eatmydata
> > https://launchpad.net/libeatmydata
> >
> > It apparently works on Linux and Solaris. Don't know if that's enough
> > coverage for general interest.

> Even though the eatmydata code base is small and looks easily
> portable I'd be in favour in an implementation that's native to
> svnadmin without the need to use an ld preload hack.

Well, 'svnadmin load' is far from the only time eatmydata is useful to
a sysadmin. Anything that is transaction-based and you're doing a lot
of at a time can benefit, from cleaning a spam infestation out of a
mail spool, to a package-manager-managed system upgrade in a disposable
VM.

So, in general, the advice is, "if you're doing something that involves
a lot of disk syncs, but in circumstances where you care a lot more
about speed than crash-safety, you should have a look at eatmydata." I
prefer this approach over adding a "fast but unsafe" mode to every tool
that might be used in such a situation.

                    * * *

Alternatively - this is the same speed/safety tradeoff as the famous
SVN_I_LOVE_CORRUPTED_WORKING_COPIES_SO_DISABLE_SLEEP_FOR_TIMESTAMPS.
Could we just use a similar environment variable in this case as well?
The known use case is svnadmin, which is self-contained - no need to
propagate the flag to a separate server process - so a variable would
work.

Peter
Received on 2011-12-16 18:02:46 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.