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

Re: Taking mirror Backup of SVN Repos through 3rd Party Software

From: Les Mikesell <lesmikesell_at_gmail.com>
Date: Thu, 30 Jun 2011 13:56:27 -0500

On 6/30/2011 1:15 PM, Andreas Krey wrote:
> On Thu, 30 Jun 2011 11:35:17 +0000, Les Mikesell wrote:
> ...
>> I think you are being way too optimistic about real-world filesystems
>> and disk and controller caches. It is possible to make a system that
>> behaves with the ideal behavior you describe - and maybe many do in
>> terms of the filenames and directory entries.
> Actually, more like for reads and writes into/from a single file;
> a full sync() tends to be a bit expensive.

At least for older versions of linux and some of its filesystems there
is no difference between an fsync() and a sync() because it didn't
really track the per-file dirty cache. I assume that is fixed in
current versions but don't really know. Even now, I don't think it
always propagates through the LVM and filesystem layers reliably. And if
your raid controller has a cache without a battery backup.

>> But I'd guess that the
>> majority don't really get this right with the data contents of those files.
> I can't claim that I did test the popular ones rigorously for that.
> (I'd love to, but nobody is going sponsor me on that.)
> But without some such guarantees it is impossible to implement any
> database (working in-place) in a crash-proof way, and there are quite
> a few that work apparently reliably on major operating systems,
> so I tend to regard your view as a bit pessimistic. :-)

Operating systems don't crash much anymore and systems that matter
normally have backup power. So applications can get away with bad
assumptions and no testing and if something goes wrong they blame the
hardware. But from an operations perspective it doesn't matter whether
it is a hardware, OS, or application problem, you just want to get some
usable data back. SQLlite does have a very good reputation for
durability, but I think it is from having the ability to clean up
unexpected states as much as from always doing things in the right order
and counting on the OS to do things correctly. You might note the
issues that have been reported for BDB. If you could trust the OS and
filesystem the way you would like, most of those problems would not happen.

   Les Mikesell
Received on 2011-06-30 20:57:06 CEST

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

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