diff options
author | Joey Hess <joey@kitenet.net> | 2012-07-06 17:06:05 -0600 |
---|---|---|
committer | Joey Hess <joey@kitenet.net> | 2012-07-06 17:06:05 -0600 |
commit | 2c4b39be4f68b53c2d2bc3647b17789b316fc542 (patch) | |
tree | 6f9477282ddf5ecbf4218cbfec2543e307d87b7b /doc | |
parent | 27ac0ec332d4d3cd8ee03d16b7e22d0498157b14 (diff) |
blog for the day
Diffstat (limited to 'doc')
-rw-r--r-- | doc/design/assistant/blog/day_26__dying_drives.mdwn | 28 |
1 files changed, 28 insertions, 0 deletions
diff --git a/doc/design/assistant/blog/day_26__dying_drives.mdwn b/doc/design/assistant/blog/day_26__dying_drives.mdwn new file mode 100644 index 000000000..109ceb19e --- /dev/null +++ b/doc/design/assistant/blog/day_26__dying_drives.mdwn @@ -0,0 +1,28 @@ +My laptop's SSD died this morning. I had some work from yesterday +committed to the git repo on it, but not pushed as it didn't build. +Luckily I was able to get that off the SSD, which is now a read-only +drive -- even mounting it fails with fsck write errors. + +Wish I'd realized the SSD was dying before the day before my trip to +Nicaragua.. +Getting back to a useful laptop used most of my time and energy today. + +I did manage to fix transfers to not block the rest of the assistant's +threads. Problem was that, without Haskell's threaded runtime, waiting +on something like a rsync command blocks all threads. To fix this, +transfers now are run in separate processes. + +Also added code to allow multiple transfers to run at once. Each transfer +takes up a slot, with the number of free slots tracked by a `QSemN`. +This allows the transfer starting thread to block until a slot frees up, +and then run the transfer. + +This needs to be extended to be aware of transfers initiated by remotes. +The transfer watcher thread should detect those starting and stopping +and update the `QSemN` accordingly. It would also be nice if transfers +initiated by remotes would be delayed when there are no free slots for them +... but I have not thought of a good way to do that. + +There's a bug somewhere in the new transfer code, when two transfers are +queued close together, the second one is lost and doesn't happen. +Would debug this, but I'm spent for the day. |