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

comments

Browse source
This commit is contained in:
Joey Hess 2025-08-29 11:42:33 -04:00
commit 1d51a0b0ad
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 69 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

41
doc/bugs/35_failed_tests_on_beegfs/comment_1_07b18e92f2abc25c5666f4ca83bbe1cd._comment Normal file
View file

@ -0,0 +1,41 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2025-08-29T15:16:00Z"
content="""
The failures are mostly of two varieties.
type A:
add: FAIL (2.20s)
./Test/Framework.hs:395:
checkcontent foo
expected: "annexed file content"
but got: "could not read file"
type B:
init: OK (1.98s)
add: FAIL (5.90s)
./Test/Framework.hs:92:
unlock failed with unexpected exit code (transcript follows)
unlock sha1foo cp: cannot open '.git/annex/objects/3j/xV/SHA1-s25--ee80d2cec57a3810db83b80e1b320df3a3721ffa/SHA1-s25--ee80d2cec57a3810db83b80e1b320df3a3721ffa' for reading: No such file or directory
In both cases, a `git-annex add` is succeeding, but the annex objects
directory is somehow not getting populated. Or at least, a subsequent read
of a file in it has the filesystem not knowing the file that the add put
there is there.
It seems quite likely a lot of other tests would also fail, but they are being
skipped because the add tests fail.
In one case, the add tests are succeeding (on an adjusted unlocked branch),
but then a subsequent test fails:
git-remote-annex exporttree: FAIL (8.45s)
./Test/Framework.hs:92:
export failed with unexpected exit code (transcript follows)
mv: cannot move '.git/annex/othertmp/89ddefa4-a04c-11.0/89ddefa4-a04c-11' to '.git/annex/export.ex/89ddefa4-a04c-11ef-818d8a-1-c6223d6': Device or resource busy
mv: cannot move '.git/annex/othertmp/89ddefa4-a04c-11.0/89ddefa4-a04c-11' to '.git/annex/export.ex/89ddefa4-a04c-11ef-818d8a-2-c718026': Device or resource busy
git-annex: renamePath:rename '.git/annex/othertmp/89ddefa4-a04c-11.0/89ddefa4-a04c-11' to '.git/annex/export.ex/89ddefa4-a04c-11ef-87b5-e880882a4f98': resource busy (Device or resource busy)
"""]]

28
doc/bugs/35_failed_tests_on_beegfs/comment_2_0d3117fc63c4d360423fbf834a0e7d8d._comment Normal file
View file

@ -0,0 +1,28 @@
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2025-08-29T15:31:42Z"
content="""
I'm not familiar with beegfs, but its documentation such as this
<https://doc.beegfs.io/latest/architecture/overview.html> makes me wonder if it
manages to behave consistently as we would expect a filesystem to behave.
In particular, we have a file being moved from one directory to another
directory. Beegfs's docs says it will pick a random metadata node for each
directory. So there can be two metadata nodes that have to be updated for a
move. If one node somehow lags seeing the update, could that result in the file
not appearing as present in the destination directory after the move?
I'm only speculating about how beegfs might work, but it seems unlikely that
git-annex has a bug that causes it to lose an annexed file when all it's done is
move it to the objects directory, that only manifests on this one filesystem.
A good next step might be to try manually adding an annexed file and see
if there is some lag between `git-annex add` and being able to read the content
of the symlink. Eg, compare:
echo foo > foo
git-annex add foo; cat foo
echo bar > bar
git-annex add bar; sleep 1m; cat bar
"""]]