blog for the day
This commit is contained in:
parent
6b56abf215
commit
06caf52f03
2 changed files with 31 additions and 0 deletions
30
doc/design/assistant/blog/day_9__correctness.mdwn
Normal file
30
doc/design/assistant/blog/day_9__correctness.mdwn
Normal file
|
@ -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.
|
|
@ -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.
|
||||
|
|
Loading…
Add table
Reference in a new issue