Thread (70 messages) flat view 70 messages, 12 authors, 2016-06-15

Re: [PATCH 5/6] Teach "fsck" not to follow subproject links

From: David Lang <hidden>
Date: 2016-06-15 22:43:04

On Wed, 11 Apr 2007, Linus Torvalds wrote:
On Wed, 11 Apr 2007, David Lang wrote:
quoted
would it make sense to have a --multiple-project option for fsck that would
let you specify multiple 'projects' that share a object set and have the
default checking not do the reachability checks that cause problems in this
case?
Well, the thing is, sharing object directories actually makes things
*harder* to check, rather than easier.

It can be a nice space optimization, and yes, if there really is a lot of
shared state, it can make it much cheaper to do some of the checks, but
right now we have absolutely *no* way for fsck to then do the reachability
check, because there is no way to tell fsck where all the refs are (since
now the refs come in from multiple repositories!)
this is why I was suggesting a --multiple-project option to let you tell fsck 
about all of the repositories that it needs to look for refs in.
So the individual objects get cheaper to fsck (no need to fsck shared
objects over and over again), but the reachability gets much harder to
fsck.
agreed.
It's not an insurmountable problem, or even necessarily a very large one,
but it boils down to one very basic issue:

- nobody seems to actually *use* the shared object directory model!

The thing is, with pack-files and alternates directories, a lot of the
original reasons for shared object directories simply don't exist..
I suspect that if it coudl be checked it would be used more, especially with the 
subproject support.

David Lang
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help