From b596fc482a0c930e5f1748ac2980c1001d3d80fd Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sun, 22 Feb 2015 19:48:10 -0400 Subject: [PATCH] devblog --- .../day_258__database_branch_merged.mdwn | 25 +++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 doc/devblog/day_258__database_branch_merged.mdwn diff --git a/doc/devblog/day_258__database_branch_merged.mdwn b/doc/devblog/day_258__database_branch_merged.mdwn new file mode 100644 index 0000000000..97cae78b5d --- /dev/null +++ b/doc/devblog/day_258__database_branch_merged.mdwn @@ -0,0 +1,25 @@ +I'm snowed in, but keeping busy.. + +Developed a complete workaround for the [sqlite SELECT ErrorBusy bug](http://news.gmane.org/find-root.php?message_id=20150219163255.GA13383%40kitenet.net). +So after a week, I finally have sqlite working robustly. And, I merged in +the branch that uses sqlite for incremental fsck. + +Benchmarking an incremental fsck --fast run, checking 40 thousand files, +it used to take 4m30s using sticky bits, and using sqlite slowed it down by +10s. So one added second per 4 thousand or so files. I think that's ok. +Incremental fsck is intended to be used in big repos, which are probably not +checked in --fast most, so the checksumming of files will by far swamp +that overhead. + +Also got sqlite and persistent installed on all the autobuilders. This +was easier than expected, because persistent bundles its own copy of +sqlite. + +That would have been a good stopping place for the day's work.. But then I +got to spent 5 more hours getting the EvilSplicer to support Persistent. +Urgh. :-/ + +Now I can look forward to using sqlite for something more interesting than +incremental fsck, like metadata caching for views, or the direct mode mappings. +But, given all the trouble I had with sqlite, I'm going to put that off for +a little while, to make sure that I've really gotten sqlite to work robustly.