- 04 Dec, 2019 1 commit
-
-
Jakob Unterwurzacher authored
I have suddenly seen TestTypeChange hang forever, waiting for the FORGET that never arrives. The first concern was that the assumption that the FORGET always follows the delete was wrong. Checking the kernel source code, the FORGET should really, actually always follow the delete. Looking more closely on the debug trace showed this: LOOKUP i1 [".Trash-1026"] 12b OK, {i1234 g0 tE=0s tA=0s {M0100644 SZ=0 L=0 0:0 B0*4096 i0:1234 A 0.000000 M 0.000000 C 0.000000}} This is the desktop environment looking for the trash folder. And because the test is stupid, it returned the same dummy inode i1234. This means the kernel had one extra reference to this inode and, of course, did not send a FORGET when "file" was deleted. I made testTypeChangeIno only react to expected file names now, and added a log output should we wait more than ~5 seconds for the FORGET. The log message then repeats indefinitely every 5 seconds. ~/go/src/github.com/hanwen/go-fuse/fs$ go test -v -run TestTypeChange === RUN TestTypeChange 20:50:18.491584 rx 2: INIT i0 {7.31 Ra 0x20000 CACHE_SYMLINKS,POSIX_LOCKS,SPLICE_MOVE,SPLICE_READ,READDIRPLUS,READDIRPLUS_AUTO,PARALLEL_DIROPS,ABORT_ERROR,EXPLICIT_INVAL_DATA,ASYNC_READ,EXPORT_SUPPORT,DONT_MASK,NO_OPENDIR_SUPPORT,SPLICE_WRITE,FLOCK_LOCKS,AUTO_INVAL_DATA,HANDLE_KILLPRIV,MAX_PAGES,POSIX_ACL,ATOMIC_O_TRUNC,BIG_WRITES,IOCTL_DIR,ASYNC_DIO,WRITEBACK_CACHE,NO_OPEN_SUPPORT} 20:50:18.491728 tx 2: OK, {7.28 Ra 0x20000 NO_OPEN_SUPPORT,BIG_WRITES,PARALLEL_DIROPS,READDIRPLUS,ASYNC_READ,AUTO_INVAL_DATA 0/0 Wr 0x10000 Tg 0x0} 20:50:18.491857 rx 4: ACCESS i1 {u=1026 g=1026 r} 20:50:18.491873 tx 4: OK 20:50:18.492028 rx 6: LOOKUP i1 [".go-fuse-epoll-hack"] 20b 20:50:18.492110 tx 6: 2=no such file or directory, {i0 g0 tE=0s tA=0s {M00 SZ=0 L=0 0:0 B0*0 i0:0 A 0.000000 M 0.000000 C 0.000000}} 20:50:18.492147 rx 8: CREATE i1 {0100100 [TRUNC,WRONLY,CREAT,0x8000] (00)} [".go-fuse-epoll-hack"] 20b 20:50:18.492207 tx 8: OK, {i18446744073709551615 g0 {M0100644 SZ=0 L=1 0:0 B0*0 i0:18446744073709551615 A 0.000000 M 0.000000 C 0.000000} &{18446744073709551615 0 0}} 20:50:18.492291 rx 10: LOOKUP i1 [".Trash"] 7b 20:50:18.492340 tx 10: OK, {i1234 g0 tE=0s tA=0s {M0100644 SZ=0 L=0 0:0 B0*4096 i0:1234 A 0.000000 M 0.000000 C 0.000000}} 20:50:18.492354 rx 12: POLL i18446744073709551615 20:50:18.492359 tx 12: 38=function not implemented 20:50:18.492370 rx 14: LOOKUP i1 [".go-fuse-epoll-hack"] 20b 20:50:18.492378 tx 14: 2=no such file or directory, {i0 g0 tE=0s tA=0s {M00 SZ=0 L=0 0:0 B0*0 i0:0 A 0.000000 M 0.000000 C 0.000000}} 20:50:18.492389 rx 16: GETATTR i1234 {Fh 0} 20:50:18.492398 tx 16: OK, {tA=0s {M0100644 SZ=0 L=0 0:0 B0*4096 i0:1234 A 0.000000 M 0.000000 C 0.000000}} 20:50:18.492412 rx 18: FLUSH i18446744073709551615 {Fh 18446744073709551615} 20:50:18.492417 tx 18: 5=input/output error 20:50:18.492427 rx 20: LOOKUP i1 [".go-fuse-epoll-hack"] 20b 20:50:18.492435 tx 20: 2=no such file or directory, {i0 g0 tE=0s tA=0s {M00 SZ=0 L=0 0:0 B0*0 i0:0 A 0.000000 M 0.000000 C 0.000000}} 20:50:18.492450 rx 22: RELEASE i18446744073709551615 {Fh 18446744073709551615 WRONLY,0x8000 L0} 20:50:18.492456 tx 22: 5=input/output error 20:50:18.492469 rx 24: LOOKUP i1 ["file"] 5b 20:50:18.492477 tx 24: OK, {i1234 g0 tE=0s tA=0s {M0100644 SZ=0 L=0 0:0 B0*4096 i0:1234 A 0.000000 M 0.000000 C 0.000000}} 20:50:18.492489 rx 26: LOOKUP i1 [".Trash-1026"] 12b 20:50:18.492497 tx 26: OK, {i1234 g0 tE=0s tA=0s {M0100644 SZ=0 L=0 0:0 B0*4096 i0:1234 A 0.000000 M 0.000000 C 0.000000}} 20:50:18.492506 rx 28: GETATTR i1234 {Fh 0} 20:50:18.492513 tx 28: OK, {tA=0s {M0100644 SZ=0 L=0 0:0 B0*4096 i0:1234 A 0.000000 M 0.000000 C 0.000000}} 20:50:18.492521 rx 30: GETATTR i1234 {Fh 0} 20:50:18.492528 tx 30: OK, {tA=0s {M0100644 SZ=0 L=0 0:0 B0*4096 i0:1234 A 0.000000 M 0.000000 C 0.000000}} 20:50:18.492537 rx 32: LOOKUP i1 ["file"] 5b 20:50:18.492545 tx 32: OK, {i1234 g0 tE=0s tA=0s {M0100644 SZ=0 L=0 0:0 B0*4096 i0:1234 A 0.000000 M 0.000000 C 0.000000}} 20:50:18.492555 rx 34: FORGET i18446744073709551615 {Nlookup=1} 20:50:18.492575 rx 36: UNLINK i1 ["file"] 5b 20:50:18.492588 tx 36: OK 20:50:18.492621 rx 38: LOOKUP i1 ["dir"] 4b [hangs here] Change-Id: Ibee48faf09c5a8993dfc7bb75251551f699cd63e
-
- 03 Dec, 2019 2 commits
-
-
Han-Wen Nienhuys authored
Options.ServerCallbacks can set the callbacks used when not mounting the filesystem. Change-Id: I51bf875a816c23e587ec8b575110221bdfcdaffe
-
Han-Wen Nienhuys authored
This provides more fidelity for reproducing file system behavior. Case in point, it lets us rename a directory on top of an existing directory Fixes #55. Change-Id: I82572aae32ee225b1629303c448a09f1066eb4ed
-
- 26 Nov, 2019 2 commits
-
-
Jakob Unterwurzacher authored
ListXAttr called with an empty buffer returns the current size of the list but does not touch the buffer (see man 2 listxattr). Fixes the xfstests generic/020 crash. Fixes https://github.com/hanwen/go-fuse/issues/337 . Add test Co-authored-by:
Han-Wen Nienhuys <hanwen@google.com> Change-Id: I94c94bc56fdf506d2eb924b246336b787fa2976a
-
Jakob Unterwurzacher authored
The tests sometimes hang in a way that "go test -timeout" does not work anymore. Example: https://travis-ci.org/hanwen/go-fuse/jobs/609260654 Use the external "timeout" command as backup, triggering 1 minute later. Also, the test that seems to hang is "fs", run it alone first in the hope of getting more info. Add "set -e" so executing stops if the first step fails ( https://github.com/travis-ci/travis-ci/issues/1066 ) Also add "-failfast" to "go test" so the failures are not buried in later output. All failure modes are easier to analyze now in my opinion, as you just have to scroll to the bottom to see what is going on. Examples: * https://travis-ci.com/rfjakob/go-fuse/jobs/254766675 TestStatFs failure due to non-deterministic test, stopped by -failfast) * https://travis-ci.com/rfjakob/go-fuse/jobs/254766676 Hang in TestParallelDiropsHang, stopped by -timeout, backtrace available * https://travis-ci.com/rfjakob/go-fuse/jobs/254766677 Hang somewhere in "go test ./...", killed by "timeout -k 10". No backtrace, unfortunately, but at least it took 6 minutes instead of 10. Change-Id: I8069d22863c178b5c9c4d0c40f13dccfdfd0873d
-
- 25 Nov, 2019 6 commits
-
-
Jakob Unterwurzacher authored
When a inode is deleted and recreated, the inode number may be reused, and it may appear that it has changed type. A simple solution is to wait for the FORGET that *always* follows the deletion. This is what this patch does. Makes fsstress happy (tested with fsstress-loopback.bash from gocryptfs, which is similar to xfstests generic/013). Also fixes the test that was introduced in the last commit (TestTypeChange). fsstress-loopback.bash before: ~/go/src/github.com/rfjakob/gocryptfs/tests/stress_tests$ ./fsstress-loopback.bash Recompile go-fuse loopback Waiting for mount: ok Starting fsstress loop 1 fsstress.1 seed = 1572931176 fsstress.2 seed = 1572919573 fsstress.3 seed = 1573005097 rm rm: cannot remove '/var/tmp/fsstress-loopback.bash.qgK.mnt/fsstress.2/p4/d1XXXX': Is a directory rm: cannot remove '/var/tmp/fsstress-loopback.bash.qgK.mnt/fsstress.2/p6/d0/d44XXXXXXXXXXXX/d4cXXXX': Is a directory rm: cannot remove '/var/tmp/fsstress-loopback.bash.qgK.mnt/fsstress.3/p1/d11/d124/d12f/d154/d15a/d143/df1/d100/d135/d123/d3a': Is a directory rm: cannot remove '/var/tmp/fsstress-loopback.bash.qgK.mnt/fsstress.3/p1/d11/f22': Not a directory rm: cannot remove '/var/tmp/fsstress-loopback.bash.qgK.mnt/fsstress.3/p3/d0/d7e/d4b/d102/d157/d134/d12f/d14b/d17a/d130': Is a directory rm: cannot remove '/var/tmp/fsstress-loopback.bash.qgK.mnt/fsstress.3/p3/d0/d7e/d4b/d102/d157/d158/df2/ff5': Not a directory rm: cannot remove '/var/tmp/fsstress-loopback.bash.qgK.mnt/fsstress.3/p3/d0/d1c': Is a directory rm: cannot remove '/var/tmp/fsstress-loopback.bash.qgK.mnt/fsstress.3/p0/d0/d4': Is a directory rm: cannot remove '/var/tmp/fsstress-loopback.bash.qgK.mnt/fsstress.3/p2/d6/dfd/da6/df2/d124/dea/d100/d120/d131/d13e/d13b/d149/d13a/f9c': Not a directory rm: cannot remove '/var/tmp/fsstress-loopback.bash.qgK.mnt/fsstress.3/p2/d6/dfd/da6/df2/d124/dea/dd5/dfa/d127/d129/d14a/d117/d14c/d82': Is a directory ./fsstress-loopback.bash: line 1: kill: %1: no such job After (with typechangeDebug = true): $ ./fsstress-loopback.bash Recompile go-fuse loopback Waiting for mount: ok Starting fsstress loop 1 fsstress.1 seed = 1574198874 fsstress.2 seed = 1574016238 17:51:25.770396 Ino:13634604 typechange 0x8000 -> 0xa000, sleep=0s 17:51:25.890382 Ino:13899580 typechange 0xa000 -> 0x8000, sleep=0s 17:51:25.890400 Ino:13899580 typechange 0xa000 -> 0x8000, sleep=1µs 17:51:25.890412 Ino:13899580 typechange 0xa000 -> 0x8000, sleep=1.41µs fsstress.3 seed = 1574847533 17:51:27.472057 Ino:14158985 typechange 0x4000 -> 0x8000, sleep=0s 17:51:27.472070 Ino:14158985 typechange 0x4000 -> 0x8000, sleep=1µs 17:51:27.472304 Ino:14158985 typechange 0x8000 -> 0x4000, sleep=0s 17:51:27.478628 Ino:14159000 typechange 0x8000 -> 0x4000, sleep=0s 17:51:27.478640 Ino:14159000 typechange 0x8000 -> 0x4000, sleep=1µs 17:51:27.478700 Ino:14159000 typechange 0x8000 -> 0x4000, sleep=1.051µs 17:51:27.478747 Ino:14159000 typechange 0x8000 -> 0x4000, sleep=1.817µs 17:51:27.478796 Ino:14159000 typechange 0x8000 -> 0x4000, sleep=3.18µs 17:51:27.478840 Ino:14159000 typechange 0x8000 -> 0x4000, sleep=5.718µs 17:51:27.478884 Ino:14159000 typechange 0x8000 -> 0x4000, sleep=8.396µs 17:51:27.478976 Ino:14159000 typechange 0x8000 -> 0x4000, sleep=10.784µs 17:51:27.479024 Ino:14159000 typechange 0x8000 -> 0x4000, sleep=13.017µs 17:51:27.479067 Ino:14159000 typechange 0x8000 -> 0x4000, sleep=16.065µs 17:51:27.479108 Ino:14159000 typechange 0x8000 -> 0x4000, sleep=19.767µs 17:51:27.479145 Ino:14159000 typechange 0x8000 -> 0x4000, sleep=27.427µs 17:51:27.479240 Ino:14159000 typechange 0x8000 -> 0x4000, sleep=36.272µs 17:51:27.500756 Ino:14291431 typechange 0x4000 -> 0x8000, sleep=0s 17:51:27.500770 Ino:14291431 typechange 0x4000 -> 0x8000, sleep=1µs 17:51:27.500779 Ino:14291431 typechange 0x4000 -> 0x8000, sleep=1.873µs 17:51:27.521194 Ino:14291506 typechange 0x4000 -> 0x8000, sleep=0s 17:51:27.521207 Ino:14291506 typechange 0x4000 -> 0x8000, sleep=1µs rm 2 fsstress.1 seed = 1574600636 fsstress.2 seed = 1574203490 17:51:29.009666 Ino:12209562 typechange 0x4000 -> 0xa000, sleep=0s 17:51:29.010068 Ino:12209562 typechange 0x4000 -> 0xa000, sleep=1µs 17:51:29.010078 Ino:12209562 typechange 0x4000 -> 0xa000, sleep=1.79µs 17:51:29.010179 Ino:12209562 typechange 0x4000 -> 0xa000, sleep=3.331µs 17:51:29.010255 Ino:12209562 typechange 0x4000 -> 0xa000, sleep=4.537µs 17:51:29.010364 Ino:12209562 typechange 0x4000 -> 0xa000, sleep=8.354µs 17:51:29.010416 Ino:12209562 typechange 0x4000 -> 0xa000, sleep=8.897µs fsstress.3 seed = 1573917850 17:51:33.623359 Ino:14291439 typechange 0x8000 -> 0x4000, sleep=0s 17:51:33.623378 Ino:14291439 typechange 0x8000 -> 0x4000, sleep=1µs 17:51:33.623392 Ino:14291439 typechange 0x8000 -> 0x4000, sleep=1.378µs 17:51:33.644130 Ino:14291494 typechange 0x8000 -> 0x4000, sleep=0s 17:51:33.644151 Ino:14291494 typechange 0x8000 -> 0x4000, sleep=1µs 17:51:33.644159 Ino:14291494 typechange 0x8000 -> 0x4000, sleep=1.072µs 17:51:33.654370 Ino:14291501 typechange 0x8000 -> 0x4000, sleep=0s 17:51:33.654384 Ino:14291501 typechange 0x8000 -> 0x4000, sleep=1µs 17:51:33.654393 Ino:14291501 typechange 0x8000 -> 0x4000, sleep=1.588µs 17:51:33.654399 Ino:14291501 typechange 0x8000 -> 0x4000, sleep=2.639µs 17:51:33.655098 Ino:14291476 typechange 0x4000 -> 0x8000, sleep=0s 17:51:33.667216 Ino:14291504 typechange 0x4000 -> 0x8000, sleep=0s 17:51:33.667228 Ino:14291504 typechange 0x4000 -> 0x8000, sleep=1µs 17:51:33.667236 Ino:14291504 typechange 0x4000 -> 0x8000, sleep=1.443µs 17:51:33.667242 Ino:14291504 typechange 0x4000 -> 0x8000, sleep=2.286µs rm 3 fsstress.1 seed = 1574749722 fsstress.2 seed = 1574328972 17:51:35.220180 Ino:13771167 typechange 0x8000 -> 0xa000, sleep=0s 17:51:35.220205 Ino:13771167 typechange 0x8000 -> 0xa000, sleep=1µs 17:51:35.514144 Ino:13771355 typechange 0x4000 -> 0xa000, sleep=0s 17:51:35.514165 Ino:13771355 typechange 0x4000 -> 0xa000, sleep=1µs 17:51:35.514172 Ino:13771355 typechange 0x4000 -> 0xa000, sleep=1.739µs 17:51:35.515875 Ino:13771355 typechange 0x4000 -> 0xa000, sleep=1.969µs 17:51:35.516021 Ino:13771355 typechange 0x4000 -> 0xa000, sleep=3.744µs 17:51:35.516094 Ino:13771355 typechange 0x4000 -> 0xa000, sleep=4.308µs 17:51:35.516514 Ino:13771355 typechange 0x4000 -> 0xa000, sleep=5.112µs 17:51:35.516765 Ino:13771355 typechange 0x4000 -> 0xa000, sleep=5.299µs 17:51:35.516870 Ino:13771355 typechange 0x4000 -> 0xa000, sleep=8.169µs 17:51:36.429950 Ino:13771381 typechange 0x8000 -> 0xa000, sleep=0s 17:51:36.430068 Ino:13771381 typechange 0x8000 -> 0xa000, sleep=1µs 17:51:36.430082 Ino:13771381 typechange 0x8000 -> 0xa000, sleep=1.071µs 17:51:36.547108 Ino:13899567 typechange 0x8000 -> 0x4000, sleep=0s 17:51:36.547121 Ino:13899567 typechange 0x8000 -> 0x4000, sleep=1µs 17:51:36.547158 Ino:13899567 typechange 0x8000 -> 0x4000, sleep=1.907µs 17:51:36.547181 Ino:13899567 typechange 0x8000 -> 0x4000, sleep=2.358µs 17:51:38.112588 Ino:13771503 typechange 0x8000 -> 0xa000, sleep=0s 17:51:38.112602 Ino:13771503 typechange 0x8000 -> 0xa000, sleep=1µs 17:51:38.112611 Ino:13771503 typechange 0x8000 -> 0xa000, sleep=1.11µs 17:51:38.524020 Ino:13899675 typechange 0xa000 -> 0x8000, sleep=0s 17:51:38.524042 Ino:13899675 typechange 0xa000 -> 0x8000, sleep=1µs Change-Id: I6120ce76730018d22898127290f492fa9f85a957
-
Jakob Unterwurzacher authored
TestTypeChange simulates inode number reuse that happens on real filesystems. For go-fuse, inode number reuse can look like a file changing to a directory or vice versa. Acutally, the old inode does not exist anymore, we just have not received the FORGET yet. The test fails reliably with iteration count 100. Will be fixed in the next commit. Test failure looks like this: ~/go/src/github.com/hanwen/go-fuse/fs$ go test -run TestTypeChange -v === RUN TestTypeChange 21:43:36.065494 rx 2: INIT i0 {7.31 Ra 0x20000 MAX_PAGES,SPLICE_READ,FLOCK_LOCKS,READDIRPLUS,READDIRPLUS_AUTO,ASYNC_DIO,WRITEBACK_CACHE,HANDLE_KILLPRIV,SPLICE_WRITE,PARALLEL_DIROPS,ABORT_ERROR,EXPLICIT_INVAL_DATA,NO_OPENDIR_SUPPORT,ASYNC_READ,BIG_WRITES,DONT_MASK,IOCTL_DIR,AUTO_INVAL_DATA,POSIX_ACL,CACHE_SYMLINKS,POSIX_LOCKS,ATOMIC_O_TRUNC,EXPORT_SUPPORT,SPLICE_MOVE,NO_OPEN_SUPPORT} 21:43:36.065573 tx 2: OK, {7.28 Ra 0x20000 PARALLEL_DIROPS,AUTO_INVAL_DATA,ASYNC_READ,BIG_WRITES,NO_OPEN_SUPPORT,READDIRPLUS 0/0 Wr 0x10000 Tg 0x0} 21:43:36.065742 rx 4: LOOKUP i1 [".go-fuse-epoll-hack"] 20b 21:43:36.065798 tx 4: 2=no such file or directory, {i0 g0 tE=0s tA=0s {M00 SZ=0 L=0 0:0 B0*0 i0:0 A 0.000000 M 0.000000 C 0.000000}} 21:43:36.065837 rx 6: CREATE i1 {0100100 [WRONLY,CREAT,TRUNC,0x8000] (00)} [".go-fuse-epoll-hack"] 20b 21:43:36.065861 tx 6: OK, {i18446744073709551615 g0 {M0100644 SZ=0 L=1 0:0 B0*0 i0:18446744073709551615 A 0.000000 M 0.000000 C 0.000000} &{18446744073709551615 0 0}} 21:43:36.065945 rx 8: POLL i18446744073709551615 21:43:36.065954 tx 8: 38=function not implemented 21:43:36.066009 rx 10: FLUSH i18446744073709551615 {Fh 18446744073709551615} 21:43:36.066046 tx 10: 5=input/output error 21:43:36.066065 rx 12: RELEASE i18446744073709551615 {Fh 18446744073709551615 WRONLY,0x8000 L0} 21:43:36.066071 tx 12: 5=input/output error 21:43:36.066107 rx 14: LOOKUP i1 ["file"] 5b 21:43:36.066181 tx 14: OK, {i1234 g0 tE=0s tA=0s {M0100644 SZ=0 L=0 0:0 B0*4096 i0:1234 A 0.000000 M 0.000000 C 0.000000}} 21:43:36.066217 rx 16: GETATTR i1234 {Fh 0} 21:43:36.066240 tx 16: OK, {tA=0s {M0100644 SZ=0 L=0 0:0 B0*4096 i0:1234 A 0.000000 M 0.000000 C 0.000000}} 21:43:36.066264 rx 18: LOOKUP i1 ["file"] 5b 21:43:36.066285 tx 18: OK, {i1234 g0 tE=0s tA=0s {M0100644 SZ=0 L=0 0:0 B0*4096 i0:1234 A 0.000000 M 0.000000 C 0.000000}} 21:43:36.066301 rx 20: UNLINK i1 ["file"] 5b 21:43:36.066321 tx 20: OK 21:43:36.066361 rx 24: LOOKUP i1 ["dir"] 4b 21:43:36.066371 tx 24: OK, {i1234 g0 tE=0s tA=0s {M0100644 SZ=0 L=0 0:0 B0*4096 i0:1234 A 0.000000 M 0.000000 C 0.000000}} 21:43:36.066383 rx 22: FORGET i1234 {Nlookup=2} 21:43:36.066390 rx 26: GETATTR i1234 {Fh 0} 21:43:36.068259 tx 26: OK, {tA=0s {M0100644 SZ=0 L=0 0:0 B0*4096 i0:1234 A 0.000000 M 0.000000 C 0.000000}} 21:43:36.069664 received ENODEV (unmount request), thread exiting 21:43:36.073309 received ENODEV (unmount request), thread exiting 21:43:36.073396 received ENODEV (unmount request), thread exiting --- FAIL: TestTypeChange (0.01s) bridge_test.go:96: should be a dir now FAIL exit status 1 FAIL github.com/hanwen/go-fuse/v2/fs 0.017s Change-Id: I7a1a10303ecc0a8c008d29d5d81079868fc2cc43
-
Jakob Unterwurzacher authored
As seen in debug logs like shown below, concurrent FORGETs and inode number reuse could make use give an Inode to the kernel that has already been deleted from the nodes[] map. With this change, I can no langer trigger a panic in xfstests generic/007. Fixes https://github.com/hanwen/go-fuse/issues/324 Nodes that appear to change type are not handled yet (actually caused by inode number reuse), but this is a separate problem. Debug log: 17:09:07.651735 rx 84444: CREATE i13632136 {0100644 [WRONLY,TRUNC,CREAT,0x8000] (022)} ["XXXXXXXXXXXX.38"] 16b 17:09:07.651790 tx 84444: OK, {i13632483 g1 {M0100644 SZ=0 L=1 0:0 B0*4096 i0:13632483 A 1572192547.650470 M 1572192547.650470 C 1572192547.650470} &{7 0 0}} [...] 17:09:07.684439 rx 87988: CREATE i13632119 {0100644 [CREAT,TRUNC,WRONLY,0x8000] (022)} ["XXXXXXXXXXXX.37"] 16b [...] 17:09:07.684472 rx 87992: FORGET i13632483 {Nlookup=1} 17:09:07.684483 tx 87988: OK, {i13632483 g1 {M0100644 SZ=0 L=1 0:0 B0*4096 i0:13632483 A 1572192547.683470 M 1572192547.683470 C 1572192547.683470} &{8 0 0}} [...] 17:09:07.684557 rx 88006: FLUSH i13632483 {Fh 8} 17:09:07.684560 unknown node 13632483 17:09:07.684564 tx 88002: OK, "XXXXXXXXXXXX.830" panic: unknown node 13632483 Change-Id: Ibb1a7a6a459d2e4133a4e512e0816e8ed950a8d7
-
Jakob Unterwurzacher authored
Getting rid of the "Mounted!" message makes it easier to integrate into xfstests, which barks at all and any unexpected output. Used by https://github.com/rfjakob/fuse-xfstests/commit/ab1d77ccdb8cf16f79cb312bcb3aaadb23660807 Change-Id: Idff314474b4980ef6f6fc2460b338a840bb0e409
-
Jakob Unterwurzacher authored
As pointed out by @slackner at https://github.com/hanwen/go-fuse/commit/8581b7e950b2d520370eba8997ddd9493192e9c7#r35845728 FixMode() failed to take into account the length of the file name and the padding. To fix this without adding a lot of additional pointer arithmetic, add the "lastDirent" field to DirEntryList. This stores the last serialized _Dirent, so _Dirent.Typ can be accessed easily by FixMode(). Change-Id: I6ca3fe551e1a072779b1d5ed5293add057e55287
-
Han-Wen Nienhuys authored
Add TestReaddirTypeFixup(). This test currently fails because FixMode is broken. Will be fixed in a later commit. Change-Id: Ie4eab9c5817ddb772b73aa22e8f75f5d4f2ad49c
-
- 22 Nov, 2019 1 commit
-
-
Mark Karpeles authored
Fixes issue #314 Change-Id: I6bf2d64d0e62c4881b7010c5c0421a16bd8d7db2
-
- 08 Nov, 2019 2 commits
-
-
Han-Wen Nienhuys authored
On OSX, Fh apparently is non-zero sometimes, even with FATTR_FH unset. Fixes #329 Change-Id: I4d9b6a83a3a8e8fa615dfbfa4d1b132b752528da
-
Han-Wen Nienhuys authored
Fixes #333 Change-Id: I51ac08baaf54884749bdc7356f524f8347ca6146
-
- 07 Nov, 2019 4 commits
-
-
Jakob Unterwurzacher authored
Go 1.9 fails to build the fs tests: # github.com/kylelemons/godebug/diff ../../kylelemons/godebug/diff/diff.go:50:13: undefined: strings.Builder ? github.com/hanwen/go-fuse/example/zipfs [no test files] FAIL github.com/hanwen/go-fuse/fs [build failed] So drop Go 1.9. Add Go 1.13, which is already at 1.13.3. Change-Id: Id2286cddc3973a1388f94e1b294db36d7663c37b
-
Jakob Unterwurzacher authored
When a directory is modified while READDIRPLUS is running, the file type may change between readdir and lookup. This patch adds the function FixMode() which allows to overwrite the file type of the last serialized dirent. Add test Fixes https://github.com/hanwen/go-fuse/issues/323 Change-Id: Id45a9c4633e9abcb075588dc610ce8341d104825
-
Han-Wen Nienhuys authored
open(2) has supports direct IO. When opening a file in the loopback FS, writes to the underlying would fail, because the FUSE server does not position the bytes to write (which come directly after the WriteIn header) on a 512-byte boundary. Fix this by allocating the input buffer with such that the first content byte is aligned. Add a test. Fixes #328. Change-Id: Ib7ad24aff673413ab8db4112d0b12143c2654617
-
Han-Wen Nienhuys authored
As of Go 1.13, os.File doesn't allow WriteAt to O_APPEND. Since the kernel translates writes to correct offsets, loopback does not have to open the file as O_APPEND. Fixes #325. Change-Id: Ib1a7026b94b5604d415ac9fbb5850842dbeffc2a
-
- 06 Nov, 2019 2 commits
-
-
Han-Wen Nienhuys authored
Change-Id: I436dcd5f4a050ef082684af0705df9c51d6ff9e9
-
Han-Wen Nienhuys authored
There are two types of DIRECT_IO. The one documented in open(2) and FUSE's FOPEN_DIRECT_IO feature. This test exercises the latter. Change-Id: Ie834b126318dedf5f65f0cf9805019ccda531797
-
- 03 Nov, 2019 3 commits
-
-
Jakob Unterwurzacher authored
Travis CI has a no-output-timeout of 10 minutes. Set a lower test timeout so we get proper backtraces on a hung test. Actual test runtime should be about 1 minute. Change-Id: I3fb40d13fb5bf9efc5e96f3551733205a7502481
-
Jakob Unterwurzacher authored
gocryptfs has a similar test with somewhat more detailed parsing of the open fds. Import the ListFds function from gocryptfs and use it to make the error more informative. Change-Id: I2442364e2e5d49749683072b91bda5691ad8902e
-
Jakob Unterwurzacher authored
These are not actual directories, and adding them to our tree causes directory cycles, so don't. Before this change, running $ ./extractloop.bash -loopback from https://github.com/rfjakob/gocryptfs/tree/master/tests/stress_tests quickly caused loopback to get stuck and consume all available memory. Things look stable now. Add a test to verify that rawBridge does not call LOOKUP on "." and "..". Also, add a comment to the "for pd = range p.parents" loop, that has caused some head-scratching during debugging. Change-Id: I15eedeee30043dc57e5fa580fefe59a48674b193
-
- 19 Oct, 2019 4 commits
-
-
Jakob Unterwurzacher authored
Even when the directory stream does not have additional entries, we may still have an entry in the overflow slot. Don't forget about it. Test now passes: go-fuse/fs$ go test PASS ok github.com/hanwen/go-fuse/v2/fs 0.582s Change-Id: I98b39d4e7df235ed57ae4bf2702532f3b17d1bd0
-
Jakob Unterwurzacher authored
There is an unhandled corner case in the directory stream handling. The stricter test catches it: go-fuse/fs$ go test --- FAIL: TestPosix (0.20s) --- FAIL: TestPosix/ReadDir (0.09s) test.go:342: got 19 entries, want 20 test.go:342: got 40 entries, want 41 test.go:342: got 61 entries, want 62 test.go:342: got 82 entries, want 83 test.go:342: got 103 entries, want 104 FAIL exit status 1 FAIL github.com/hanwen/go-fuse/v2/fs 0.610s Fix comes next. Change-Id: I3e22904fce96bf2264ede47656ebd2936a7d13cd
-
Jakob Unterwurzacher authored
Filesystems usually show the underlying device in the first column of df. Follow suite and show the original dir, making "df" and "mount" output more useful. The actual reason for this change, however, is that it facilitates running xfstests against go-fuse loopback. The xfstests machinery checks that the expected device is mounted at the right place. Commit https://github.com/rfjakob/fuse-xfstests/commit/182841fea487419f493d9b547bf703bee9e39322 adds support for go-fuse loopback to xfstests and depends on this change. Before: $ df -T Filesystem Type 1K-blocks Used Available Use% Mounted on loopback fuse.loopback 237371192 149885928 75357828 67% /home/jakob/go/src/github.com/hanwen/go-fuse/example/loopback/b After: $ df -T Filesystem Type 1K-blocks Used Available Use% Mounted on a fuse.loopback 237371192 150332024 74911732 67% /home/jakob/go/src/github.com/hanwen/go-fuse/example/loopback/b Change-Id: I3d5a2e7ab021af4eed657e66654b636e08292219
-
Jakob Unterwurzacher authored
Per default, "rawBridge" is shown here, which does not tell the user much about the filesystem. Set to "loopback" as shown below. Before: $ df -T Filesystem Type 1K-blocks Used Available Use% Mounted on rawBridge fuse.rawBridge 237371192 149873220 75370536 67% /home/jakob/go/src/github.com/hanwen/go-fuse/example/loopback/b After: $ df -T Filesystem Type 1K-blocks Used Available Use% Mounted on loopback fuse.loopback 237371192 149885928 75357828 67% /home/jakob/go/src/github.com/hanwen/go-fuse/example/loopback/b Change-Id: Iaaa18b4193b31567f6589669e8c443715afbd362
-
- 04 Oct, 2019 3 commits
-
-
Han-Wen Nienhuys authored
Add posix.LinkUnlinkRename to test this behavior; this is the approach that git uses for writing pack files. Thanks to Nicola Girardi <idrarig.alocin@gmail.com> for reporting this bug. Change-Id: Idb34e32f1dbb3c6c617aa82e29c4f0ac6f8a544d
-
Han-Wen Nienhuys authored
Change-Id: Ie50ade19cf86abbbc6d6d5710f26ca03d7873098
-
Jakob Unterwurzacher authored
Failure was: zipfs_test.go:74: got block count 8, want 1 This got broken by "fs: set Blksize and Blocks automatically based on Size", fix it by setting Blksize. Change-Id: I1d3798082b2e8a7fcda908b9b88d8b51fb11da78
-
- 16 Sep, 2019 2 commits
-
-
Han-Wen Nienhuys authored
Change-Id: I272909148667e1f0246914ef7fdd1052bf3b5bc3
-
Han-Wen Nienhuys authored
Change-Id: I1c098b6c06ab62aa7877e47aa3d99f37e9a83e5c
-
- 05 Aug, 2019 1 commit
-
-
Han-Wen Nienhuys authored
Change-Id: Iac5c1a8329ceb0d8538029bd737cfede2af4d9a2
-
- 02 Aug, 2019 2 commits
-
-
Han-Wen Nienhuys authored
Change-Id: I811c6a070bfdc3582da816f302354f4a7516beab
-
Han-Wen Nienhuys authored
Change-Id: I7dfd919df765679bf9c09ec74cefc6c53bfc56b3
-
- 26 Jul, 2019 2 commits
-
-
Han-Wen Nienhuys authored
Travis CI appears to be too slow for the race detector. Change-Id: I5f4e7dc379938cf8000ab2d8ba95e09fab8ed6c9
-
Han-Wen Nienhuys authored
Pool.Get() can trigger a GC, and we see this GC being hung in stack traces for the TestDeleteNotify test case. See issue #261. Change-Id: I278a05fc3c6a59c701686aebd410511c5502d9d5
-
- 25 Jul, 2019 1 commit
-
-
Han-Wen Nienhuys authored
Reported-by: Philipp Gillé Change-Id: I3db9f54016c17744bafa57a813531a99c01e47fa
-
- 20 Jul, 2019 2 commits
-
-
Han-Wen Nienhuys authored
The API is poorly thought out, as a node can be child in multiple parents with the same name. Similary, a reversing keys and values is not possible. A child may have the same parent with different names. Change-Id: I3888606016b56f06d80ef56ebc7b8725a819c1a9
-
Han-Wen Nienhuys authored
Change-Id: I451f56511a2b796c6a90df49e6c288d6675af363
-