fs: TestStaleHardlinks is flaky #478
Comments
|
Reliable way to reproduce: (neo) (z-dev) (g.env) kirr@deca:~/src/neo/src/github.com/hanwen/go-fuse/fs$ go test -run TestStaleHardlinks -count 1000 -failfast
--- FAIL: TestStaleHardlinks (0.00s)
simple_test.go:675: no such file or directory
FAIL
exit status 1
FAIL github.com/hanwen/go-fuse/fs 0.081s
(neo) (z-dev) (g.env) kirr@deca:~/src/neo/src/github.com/hanwen/go-fuse/fs$ go test -run TestStaleHardlinks -count 1000 -failfast
--- FAIL: TestStaleHardlinks (0.00s)
simple_test.go:675: no such file or directory
FAIL
exit status 1
FAIL github.com/hanwen/go-fuse/fs 0.918s
(neo) (z-dev) (g.env) kirr@deca:~/src/neo/src/github.com/hanwen/go-fuse/fs$ go test -run TestStaleHardlinks -count 1000 -failfast
--- FAIL: TestStaleHardlinks (0.01s)
simple_test.go:675: no such file or directory
FAIL
exit status 1
FAIL github.com/hanwen/go-fuse/fs 6.869sgo-fuse |
|
this test was introdcued in c318613 by @rfjakob . It's not representative of a correctly written FUSE filesystem (the "behind the back" deletions should be coupled with notifications back to the kernel). the follow-on a90e1f4 says that the test is fixed now, but I don't understand why that would make it work. |
|
What I meant with "behind the back" is that somebody else is modifying your backing file store (if you have one, like loopback or gocryptfs). That can happen when your files are on NFS or something and another host modifies it, or sync tools like Dropbox doing their thing. But in any case, the test should not blow up, I'll try to take a look. |
|
Oh. Excerpt below, full log here: https://gist.github.com/rfjakob/e812730df3918122c3393d010ed4db43 tx 206 gets heavily delayed after other LOOKUPs have succeeded. |
|
@rfjakob - any update here? |
|
Sorry, no, other things going on. Could you t.Skip() it for now?
…On Sat, 9 Sept 2023, 11:57 Han-Wen Nienhuys, ***@***.***> wrote:
@rfjakob <https://github.com/rfjakob> - any update here?
—
Reply to this email directly, view it on GitHub
<#478 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACGA77E6G7JLIR2AZQ2JYDXZQ4SJANCNFSM6AAAAAAZDD2N7M>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I can still repro, but not reliably, and the logs are noisy. Looks like strace shows: |
|
The extra LOOKUPs from gvfsd-trash race against the test logic. |
|
Thanks, @rfjakob. |
|
P.S. https://review.gerrithub.io/c/hanwen/go-fuse/+/1195362 was submitted but did not appear in master on github. Probably there is again gerrithub -> github synchronization issue. |
It is sometimes helpful to know which process accesses the filesystem. Relates-to: #478 Change-Id: Ie435d093f03a32c02f02b45df880a207c5d7cad1
From #351 (comment) :
I was running tests in a loop as:
and got breakage in fs in ~ 5 minutes:
go-fuse: v2.3.0-5-g90b055a
os: Linux deca 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08) x86_64 GNU/Linux
go: go version go1.20.5 linux/amd64
I also do see fs tests failing on github CI, e.g. here: https://github.com/hanwen/go-fuse/actions/runs/5210956777/jobs/9402681092#step:6:48 .
The text was updated successfully, but these errors were encountered: