JGit is unable to discover bitmaps on filesystem
Closed this issue · 1 comments
Version
All releases from v4.10.* onwards
Operating System
Linux/Unix
Bug description
Context
Bare repos can be at time transferred at the filesystem level (with the target location in read-only until the transfer is complete) across Gerrit servers.
I am running on defaults for JGit and Gerrit.
Example:
- Server-1 (read-only) has repo1.git bare repository
- Server-2 (read-only) receives repo1.git via rsync and stay in read-only until the transfer is complete
I do not see anything wrong with the above approach, as long as Server-2 is read-only until the transfer is complete.
Steps to reproduce the problem
- Rsync repo1.git repo with the exception of the bitmap
- run a git clone against Server-2 / repo1.git using Git/SSH
- Observe on the Server-2 in the sshd_log that the bitmap is not used
- Complete the rsync of repo1.git, which will transfer the bitmap
- run a git clone against Server-2 / repo1.git using Git/SSH
Actual behavior
At point 5. the sshd_log shows that the bitmap is not used. After a full restart of Gerrit, the action 5. reports that the bitmap is used in the sshd_log.
Expected behavior
At point 5. the sshd_log shows that the bitmap is used
Relevant log output
See the log of the sshd_log execution on a Gerrit v3.5.6 (JGit 6.6.0 @74fa245b3c3ccf13afcbec7911c7c8459e48527d)
At point 2. clone without bitmap:
[2024-01-12T10:32:32.491Z] 33cc307a [SSH git-upload-pack /repo1 (admin)] admin a/1000000 git-upload-pack./repo1 5ms 55ms '0ms 27ms 0ms 8ms 0ms 4ms 39ms -1 141 440 37967' 0 - 47ms 40ms 1493344
At point 5. clone with bitmap:
[2024-01-12T10:39:22.108Z] 53bd24d6 [SSH git-upload-pack /repo1 (admin)] admin a/1000000 git-upload-pack./repo1 6ms 54ms '0ms 28ms 0ms 7ms 0ms 4ms 39ms -1 141 440 37967' 0 - 42ms 30ms 1474304
After a Gerrit restart, at point 5. clone with bitmap:
[2024-01-12T10:40:37.388Z] a5799f52 [SSH git-upload-pack /repo1 (admin)] admin a/1000000 git-upload-pack./repo1 4ms 60ms '0ms 39ms 0ms 1ms 0ms 5ms 45ms 0 141 440 37971' 0 - 54ms 40ms 895768
Other information
See Change 1174396