mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

devblog

Browse source
This commit is contained in:
Joey Hess 2013-10-05 17:26:17 -04:00
parent 635c9a1549
commit feef7d3800
2 changed files with 26 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
doc/design/assistant/disaster_recovery.mdwn
View file

@ -10,7 +10,7 @@ check that nothing else is using it, fix the problem, and redo the commit.
* **done** for .git/annex/index.lock, can be handled safely and automatically. * **done** for .git/annex/index.lock, can be handled safely and automatically.
* **done** for .git/index.lock, only when the assistant is starting up. * **done** for .git/index.lock, only when the assistant is starting up.
* What about local remotes, eg removable drives? git-annex does attempt * What about local remotes, eg removable drives? git-annex does attempt
to commit to the git-annex branch of those. It will use the atomatic to commit to the git-annex branch of those. It will use the automatic
fix if any are dangling. It does not commit to the master branch; indeed fix if any are dangling. It does not commit to the master branch; indeed
a removable drive typically has a bare repository. So I think nothing to a removable drive typically has a bare repository. So I think nothing to
do here. do here.
@ -18,13 +18,19 @@ check that nothing else is using it, fix the problem, and redo the commit.
it can take care of it, and if not, it's a server, and perhaps the user it can take care of it, and if not, it's a server, and perhaps the user
should be required to fix up if it crashes during a commit. This should should be required to fix up if it crashes during a commit. This should
not affect the assistant anyway. not affect the assistant anyway.
* TODO Seems that refs can also have stale lock files, for example * **done** Seems that refs can also have stale lock files, for example
'/storage/emulated/legacy/DCIM/.git/refs/remotes/flick_phonecamera/synced/git-annex.lock' '/storage/emulated/legacy/DCIM/.git/refs/remotes/flick_phonecamera/synced/git-annex.lock'
All git lock files are now handled (except gc lock files).
## incremental fsck ## incremental fsck
Add webapp UI to enable incremental fsck, and choose when to start and how Add webapp UI to enable incremental fsck, and choose when to start and how
long to run each day. long to run each day, and what the goal is (ie, to fsck all files once
per month).
Of course, incremental fsck will run as an niced (and ioniced) background
job. There will need to be a button in the webapp to stop it, in case it's
annoying.
When fsck finds a damanged file, queue a download of the file from a When fsck finds a damanged file, queue a download of the file from a
remote. If no accessible remote has the file, prompt the user to eg, connect remote. If no accessible remote has the file, prompt the user to eg, connect

17
doc/devblog/day_28__lazy_saturday.mdwn Normal file
View file

@ -0,0 +1,17 @@
Finished up the automatic recovery from stale lock files. Turns out git
has quite a few lock files; the assistant handles them all.
Improved URL and WORM keys so the filenames used for them
will always work on FAT (which has a crazy assortmeny of illegal
characters). This is a tricky thing to deal with without breaking backwards
compatability, so it's only dealt with when creating new URL or WORM keys.
-----
I think my next step in this disaster recovery themed month will be adding
periodic incremental fsck to the assistant. `git annex fsck` can already
do an incremental fsck, so this should mostly involve adding a user
interface to the webapp to configure when it should fsck. For example, you
might choose to run it for up 1 hour every night, with a goal of checking
all your files once per month. Also will need to make the assistant do
something useful when fsck finds a bad file (ie, queue a re-download).