From 06caf52f03de118e08dbe368d431835b5a8e6bd6 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 14 Jun 2012 20:06:43 -0400 Subject: blog for the day --- doc/design/assistant/blog/day_9__correctness.mdwn | 30 +++++++++++++++++++++++ doc/design/assistant/inotify.mdwn | 1 + 2 files changed, 31 insertions(+) create mode 100644 doc/design/assistant/blog/day_9__correctness.mdwn (limited to 'doc/design') diff --git a/doc/design/assistant/blog/day_9__correctness.mdwn b/doc/design/assistant/blog/day_9__correctness.mdwn new file mode 100644 index 000000000..1fa4c09d0 --- /dev/null +++ b/doc/design/assistant/blog/day_9__correctness.mdwn @@ -0,0 +1,30 @@ + git merge watch_ + +My cursor has been mentally poised here all day, but I've been reluctant to +merge watch into master. It seems solid, but is it correct? I was able to +think up a lot of races it'd be subject to, and deal with them, but did I +find them all? + +Perhaps I need to do some automated fuzz testing to reassure myself. +I looked into using [genbackupdata](http://liw.fi/genbackupdata/) to that +end. It's not quite what I need, but could be +[moved in that direction](http://bugs.debian.org/677542). Or I could write +my own fuzz tester, but it seems better to use someone else's, because +a) laziness and b) they're less likely to have the same blind spots I do. + +My reluctance to merge isn't helped by the known bugs with files that are +either already open before `git annex watch` starts, or are opened by two +processes at once, and confuse it into annexing the still-open file when one +process closes it. + +I've been thinking about just running `lsof` on every file as it's being +annexed to check for that, but in the end, `lsof` is too slow. Since its +check involves trawling through all of /proc, it takes it a good half a +second to check a file, and adding 25 seconds to the time it takes to +process 100 files is just not acceptable. + +But an option that could work is to run `lsof` after a bunch of new files +have been annexed. It can check a lot of files nearly as fast as a single +one. In the rare case that an annexed file is indeed still open, it could +be moved back out of the annex. Then when its remaining writer finally +closes it, another inotify event would re-annex it. diff --git a/doc/design/assistant/inotify.mdwn b/doc/design/assistant/inotify.mdwn index c9b1d60bf..9d8857ab6 100644 --- a/doc/design/assistant/inotify.mdwn +++ b/doc/design/assistant/inotify.mdwn @@ -18,6 +18,7 @@ There is a `watch` branch in git that adds the command. Possible fixes: * Somehow track or detect if a file is open for write by any processes. + `lsof` could be used, although it would be a little slow. * Or, when possible, making a copy on write copy before adding the file would avoid this. * Or, as a last resort, make an expensive copy of the file and add that. -- cgit v1.2.3