Trent Fisher wrote on Wed, Jan 15, 2020 at 15:00:56 -0500:
> On 1/6/2020 1:42 PM, Daniel Shahaf wrote:
> > Trent Fisher wrote on Mon, 06 Jan 2020 18:22 +00:00:
> > > This seems like a bug in lslocks, why would it not list *all* the locks?
> > If you run fsfs, it might be https://urldefense.proofpoint.com/v2/url?u=https-3A__subversion.apache.org_issue3750&d=DwIBAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=ZbaTjKb7ivmk5rbWkuwu4Mqvrh_gmetmbEk2XMe0cVs&m=HvcvPbSptrAq78THvePuzylhdDLG4ABfI9Y5NXg15ac&s=c8ls12Aj8kxq6gQ4jXAltM3ipA4nFCLssJk0XndlTuU&e= .
>
> So, from that, it sounds like copying a repository could result in the locks
> data structures in FSFS becoming inconsistent? This would make sense as I
> am working with an rsync'ed copy of a repository (though the bug seems to be
> saying that even hotcopy can end up with this problem)
FSFS never blocks readers. That's (part of) why both rsync and hotcopy can
trigger the problem.
For rsync, you could avoid the problem by running it like this:
rsync -a --delete repo/ repo.copy/
rsync -a --delete repo/ repo.copy/
svnadmin freeze -- repo rsync -a --delete repo/ repo.copy/
(You can run rsync any number of times before running it once with freeze.)
> Is there a way to either fix the lock database to be consistent, or just to
> clear it?
Well, I have to give you the obligatory warning never to touch anything under
$REPO_DIR/db/ [except $REPO_DIR/db/fsfs.conf] and that doing so falls under "if
you break it you get to keep both pieces". With that in mind, if I remember
correctly, svnadmin freeze repo -- rm -rf repo/db/locks/*/ will wipe the locks
database cleanly. But make sure you have backups.
The format of the locks/ directory is one svn_hash_write2() file per path that
is locked or that is an ancestor (path-wise, not revision-wise) of a locked
path, as specified in subversion/libsvn_fs_fs/structure. Using this
information a tool could be written that repairs the locks/ directory. I don't
know if anyone has done this exercise already.
Cheers,
Daniel
Received on 2020-01-15 21:32:01 CET