comments
This commit is contained in:
parent
06a44093d6
commit
1d51a0b0ad
2 changed files with 69 additions and 0 deletions
|
@ -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)
|
||||
"""]]
|
|
@ -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
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue