Re: [RFC/PATCH 8/8] read-cache: unlink old sharedindex files

On Wed, Jul 13, 2016 at 5:16 PM, Duy Nguyen [off-list ref] wrote:

On Tue, Jul 12, 2016 at 9:45 PM, Christian Couder
[off-list ref] wrote:

quoted

On Tue, Jul 12, 2016 at 5:12 PM, Duy Nguyen [off-list ref] wrote:

quoted

No. People could create an index file anywhere in theory. So you don't
know how many index files there are.

Maybe when an index file is created, its path and its sharedindex file
could be appended into a log file.
We could check this log file to see if we can remove sharedindex files.
We would need to remove the entries in this log file for the indexes
that are no longer there.

Or instead of one log file we could have a file for each index file in
a special directory called for example "indexinfo".
So we could just delete the file if its related index is no longer there.

New files will require locking so people don't append at the same
time.

If we create a new file for each index file with a name that depends
on the index path (for example maybe the sha1 of the index path) then
as many index files with the same path are not possible we should be
safe.

And maybe another new host of problems. I think we can just go
with the garbage collection way that we have done for unreachable
objects.

Your indexinfo idea looks very close to multiple locking, an index
would lock the shared index it's linked to, preventing it from being
removed. For single locking, we can just create a file named $X.lock,
but for multiple locks, maybe we can go with
$X.lock-$index_trailing_sha1. Will it work? I don't know. Just
thinking out loud.

Isn't is possible that the same index (so with the same trailing sha1)
be created in two different places?

quoted

quoted

It really depends. If the shared part is too small for old indexes, we
might as well unsplit them. In practice though, the only long-term
index file is $GIT_DIR/index. If we don't delete old shared index
files too close to their creation time, temp index files will go away.

We could treat $GIT_DIR/index specially so that if there are no temp
index files, there should be nothing in "indexinfo".

No, temp index files are needed. And it will  be hard to treat
$GIT_DIR/index specially because updating it involves a temp index:
you first prepare a new index in $GIT_DIR/index.lock.

If the new index is always prepared in $GIT_DIR/index.lock, then there
is no problem in the first place because when my original patch calls
clean_shared_index_files() the $GIT_DIR/index.lock is taken. Or maybe
I am missing something?

If everything
goes well, you atomically rename it to $GIT_DIR/index. You may be able
to treat $GIT_DIR/index.lock special too, but that's starting to get
out of hand.