LWN: Comments on "Sleepycat and CollabNet Open Source Collaboration"

Sleepycat and CollabNet Open Source Collaboration

zblaxell — Sat, 11 Feb 2006 04:09:20 +0000

It's more like every minor release has an *entirely new* ABI, complete with C preprocessor tricks to add the current version number to every symbol in the library. On a good day this means you can link multiple versions dynamically into your executable. On a bad day this means you absolutely cannot link against some random shared library version, only the specific version your application was compiled with.

Sleepycat and CollabNet Open Source Collaboration

georgm — Thu, 09 Feb 2006 08:51:57 +0000

Ok, but what about file stability over releases?
I don't want to always get into trouble when switching to a newer db-Version. I had these problems for 2 or 3 times, then I switched to fsfs to avoid this problem.

Sleepycat and CollabNet Open Source Collaboration

Peter — Thu, 09 Feb 2006 05:08:44 +0000

Yeah, I can only think it means "automatic" in the sense of "whenever anything goes wrong, the system administrator will automatically go through a full recovery process

While I appreciate the cynicism, they really do mean automatically. This code was tested by doing normal subversion stuff but also having a thread running whose only purpose was to start a transaction then get kill -9'd. Once per second, or was it 10 times per second? Anyway, the ability for an application to avoid wedging the DB even when dying unexpectedly is new to DB 4.4, so your previous experiences aren't completely valid.

The annoying part of this announcement is that we are in the process of switching from CVS to SVN. I'll have to find out what this means w.r.t. the impact on reliability.

DB isn't the default backend. Most people recommend the FSFS backend instead, which is why it's the default. It's a little slower for some operations, and creates a huge directory (one file per revision, just like arch, so if you have 25000 revisions you get a dir with 25000 files, which doesn't perform well with certain filesystems), but it has the very nice property of not changing your old data - think of it as an append-only system. And it works over NFS, not that we'd necessarily recommend it.

Sleepycat and CollabNet Open Source Collaboration

Peter — Thu, 09 Feb 2006 04:58:33 +0000

Wait, how the HECK do you get automatic recovery from BDB?

That's what this news release is about! Using new features of BDB 4.4, it's now possible for the app to do this. Previously it was not. The Subversion BDB backend was recently hacked on for awhile (the bdb-fixes branch) mainly to add this enhancement.

By the way, I believe there's an error in the press release. They say the new stuff will be in Subversion 1.3.1, but last I heard, that's not the plan. bdb-fixes has been merged back to the development trunk, but the developers are leaning toward not merging it into the 1.3.x branch until after 1.3.1 - so probably in 1.3.2 or so. It's still new and needs a bit of time to "season" first.

Sleepycat and CollabNet Open Source Collaboration

ismail — Wed, 08 Feb 2006 13:54:57 +0000

Yeah you got me ;)

Sleepycat and CollabNet Open Source Collaboration

JoeF — Wed, 08 Feb 2006 07:42:03 +0000

Yup. Too late. I switched my svn repositories to fsfs several months ago.

Sleepycat and CollabNet Open Source Collaboration

Dom2 — Wed, 08 Feb 2006 06:42:28 +0000

To be honest, I'd still choose the FSFS over the DB4 backend. The main advantage is that because
it's bundled with subversion, something else upgrading your DB4 libraries won't suddenly stop your
version control system from working. Unfortunately, this did happen to me. I switched to FSFS
when subversion 1.1 came out and I haven't looked back...

But I still love subversion. :-)

-Dom

Sleepycat and CollabNet Open Source Collaboration

ctg — Wed, 08 Feb 2006 06:27:37 +0000

Yeah, I can only think it means "automatic" in the sense of "whenever
anything goes wrong, the system administrator will automatically go
through a full recovery process because he/she knows there isn't any
point in trying to troubleshoot the system".

db4 is the most unreliable DB system I've ever come across - not that it
has failures, but that the smallest problem seems to cause the most major
impact. Impossible to work what is going wrong - everything hangs -
sometimes shutting the system down and doing a db_recover doesn't always
work - and a full dump and restore is required. I've switched to sqlite3
- which is a bit slower but seems to work - working/slow is better than
fast/broken.

The annoying part of this announcement is that we are in the process of
switching from CVS to SVN. I'll have to find out what this means w.r.t.
the impact on reliability.

Sleepycat and CollabNet Open Source Collaboration

jwb — Wed, 08 Feb 2006 02:48:35 +0000

Wait, how the HECK do you get automatic recovery from BDB? I have a single-reader multiple-writer database system, and any time any process is killed (be it reader or writer) the whole system wedges until an administrator can issue db_recover. I'd LOVE to know how to get this automatic recovery.

Sleepycat and CollabNet Open Source Collaboration

elanthis — Wed, 08 Feb 2006 01:38:43 +0000

Do they break API? I've been under the impression that the API is pretty darn stable. Even the ABI is stable, as I understand.

It's the database format that keeps breaking.

Sleepycat and CollabNet Open Source Collaboration

ismail — Wed, 08 Feb 2006 01:23:39 +0000

Sleepycat could use a stable api, or let me put it this way: don't f*cking break
api every minor release!

Sleepycat and CollabNet Open Source Collaboration

joey — Wed, 08 Feb 2006 00:40:08 +0000

Sounds like good news for the three people who haven't switched their repos to fsfs yet..