1. 12 Jun, 2023 1 commit
  2. 11 Jun, 2023 1 commit
    • Kirill Smelkov's avatar
      fuse/test: Fix TestFopenKeepCache, take 2 · d2138350
      Kirill Smelkov authored
      In 2019 TestOpenKeepCache was first disabled in ce2558b4 (fuse/test:
      disable TestFopenKeepCache) and then reenabled in 904ef0cc (fuse/test:
      Fix TestFopenKeepCache). The latter patch hoped to fix this test
      
          - by disabling CAP_AUTO_INVAL_DATA via ExplicitDataCacheControl. This
            should stop kernel from dropping data cache on mtime change;
          - by using the same size for before and after states. This avoid hitting
            cache being dropped when kernel sees file size being changed.
      
      In other words it took actions so that the data cache is not
      unexpectedly dropped by the kernel and the test does not fail with
      seeing different content after file reopen.
      
      However the test also wants to verify that updated data can be seen
      after cache invalidation and here it was not exactly correct: the test
      requested full control over the data cache via ExplicitDataCacheControl
      mount option, but was explicitly invalidating only file attributes
      via pathfs.EntryNotify _without_ invalidating the data cache.
      
      This way the test was actually working before Linux 5.2, because those
      older kernels never negotiate CAP_EXPLICIT_INVAL_DATA(*), but starting
      from Linux 5.2 CAP_EXPLICIT_INVAL_DATA started to be negotiated, and so
      the kernel was dropping only metadata without invalidating data cache on
      EntryNotify. This started to lead to the following test failures:
      
          --- FAIL: TestFopenKeepCache (0.13s)
              cache_test.go:153: ReadFile: got "before" after notify, want "afterX"
      
      @hanwen explains in https://github.com/hanwen/go-fuse/issues/473#issuecomment-1585617107
      
          It tries to invalidate the file content by issuing an ENTRY_NOTIFY. This
          leads to different mtime returned, but in the init phase, we don´t
          return AUTO_INVAL_DATA, because setupCacheTest explicitly disables it.
      
          === RUN   TestFopenKeepCache
          12:47:49.958227 callFusermount: executing ["/usr/bin/fusermount3" "/tmp/TestFopenKeepCache1094589261/001/mnt" "-o" "subtype=pathfs.pathInode,max_read=131072"]
          12:47:49.967664 rx 2: INIT n0 {7.38 Ra 131072 FLOCK_LOCKS,IOCTL_DIR,READDIRPLUS,READDIRPLUS_AUTO,PARALLEL_DIROPS,HANDLE_KILLPRIV,ASYNC_READ,BIG_WRITES,SPLICE_WRITE,SPLICE_MOVE,WRITEBACK_CACHE,NO_OPEN_SUPPORT,POSIX_ACL,POSIX_LOCKS,EXPORT_SUPPORT,AUTO_INVAL_DATA,ASYNC_DIO,MAX_PAGES,CACHE_SYMLINKS,NO_OPENDIR_SUPPORT,DONT_MASK,SPLICE_READ,ABORT_ERROR,EXPLICIT_INVAL_DATA,ATOMIC_O_TRUNC,0x70000000} "\a\x00\x00\x00\x00\x00\x00\x00"... 48b
          12:47:49.967708 tx 2:     OK, {7.28 Ra 131072 BIG_WRITES,NO_OPEN_SUPPORT,MAX_PAGES,EXPLICIT_INVAL_DATA,ASYNC_READ,READDIRPLUS,PARALLEL_DIROPS 0/0 Wr 131072 Tg 0 MaxPages 32}
      
      -> Let's fix this.
      
      As explained in 904ef0cc we do not want to reenable AUTO_INVAL_DATA
      because then the kernel will start dropping data cache on mtime change
      and the test will start to fail in its first part - where we want to
      assert that the data stays the same until data cache is invalidated.
      
      So let's change EntryNotify to FileNotify to explicitly invalidate data
      cache when we want the file to read with new data.
      
      Hopefully fixes: https://github.com/hanwen/go-fuse/issues/473
      
      (*) see git.kernel.org/linus/ad2ba64dd489 and github.com/hanwen/go-fuse/pull/273
      
      Change-Id: I4ff0f2bef61f0217601eee6d272f7e5563b272d2
      d2138350
  3. 09 Jun, 2023 2 commits
  4. 08 Jun, 2023 2 commits
  5. 07 Jun, 2023 1 commit
  6. 25 May, 2023 1 commit
  7. 18 May, 2023 2 commits
  8. 26 Apr, 2023 1 commit
  9. 23 Apr, 2023 2 commits
  10. 21 Apr, 2023 2 commits
    • Jakob Unterwurzacher's avatar
      .github: set user_allow_other in /etc/fuse.conf · 652da3f9
      Jakob Unterwurzacher authored
      Fixes this test failure:
      
      2023/04/13 20:25:20 callFusermount: executing ["/usr/bin/fusermount3" "/tmp/TestDirectMount4166040800" "-o" "allow_other,subtype=/tmp/go-build1065896,max_read=131072"]
      /usr/bin/fusermount3: option allow_other only allowed if 'user_allow_other' is set in /etc/fuse.conf
      
      \--- FAIL: TestDirectMount (0.01s)
          mount_linux_test.go:117: fusermount exited with code 256
      
      Change-Id: I4a2a2983dd422de9360b17068ac0d8a3947d453d
      652da3f9
    • Han-Wen Nienhuys's avatar
      .github: drop Go 1.13 / 1.15, add Go 1.18/1.19 · 1e62711b
      Han-Wen Nienhuys authored
      Change-Id: Ifb84efcb76615cc492c867afb9e1840a6977d402
      1e62711b
  11. 12 Apr, 2023 2 commits
  12. 10 Apr, 2023 5 commits
  13. 09 Apr, 2023 1 commit
    • Han-Wen Nienhuys's avatar
      fs: buffer error in directory reads · 17756c7c
      Han-Wen Nienhuys authored
      Previously, if a DirStream.Next() call would return error, we would
      return the buffered data as well as the errno code in the same
      request.
      
      This would confuse the kernel, who interprets this as an invalid
      response, returning syscall.EIO to the caller.
      
      To fix this, also buffer the errno as overflow entry in the fileEntry
      struct. When we encounter an error, return thus far read entries with
      success. The following read contains just the error.
      
      For testing this properly, loopbackDirStream (which reads directory
      contents) must also buffer error returns.
      
      Change-Id: Ideb8ea6f540de9189a0f366efca0db2205e5dec3
      17756c7c
  14. 07 Apr, 2023 7 commits
  15. 05 Apr, 2023 1 commit
  16. 29 Mar, 2023 1 commit
  17. 23 Mar, 2023 1 commit
  18. 19 Mar, 2023 2 commits
  19. 21 Feb, 2023 1 commit
  20. 05 Feb, 2023 1 commit
    • ZheNing Hu's avatar
      mount: add Options{RootStableAttr} field · 615a0a7e
      ZheNing Hu authored
      - provides an optional way to set e.g. Ino and/or Gen for
        the root directory when calling fs.Mount()
      - provides unit test cases
      - partial fix for #399
      
      Change-Id: If45a0ec3c0ea06c0419913e34b3415808f9349da
      615a0a7e
  21. 30 Jan, 2023 3 commits
    • Jakob Unterwurzacher's avatar
      example: loopback: add -directmount, -directmountstrict flags · de5d9718
      Jakob Unterwurzacher authored
      Allows to enable the DirectMount{,Strict} flag through the cli,
      facilitating testing.
      
      Change-Id: I46e273ea68e6a81b4e7873802bc3b1c7760f56f0
      de5d9718
    • Jakob Unterwurzacher's avatar
      example: loopback: use FsName field · 56d54486
      Jakob Unterwurzacher authored
      Commit
      
      	17c7e2cd loopback: show original directory in "df"
      
      added the FsName field to MountOptions, but looks like
      
      	d31db957 fuse: allow setting the fsname (first column in df -T)
      
      forgot that it exists. Use it now.
      
      This will be important for DirectMount, as passing "fsname=xxx" to
      the mount syscall causes the kernel to reject with EINVAL and this
      message in dmesg:
      
      	[132274.900267] fuse: Unknown parameter 'fsname'
      
      Change-Id: Ic1233fe9306e2ce05f85189eecceecec2baa44b7
      56d54486
    • Jakob Unterwurzacher's avatar
      example: loopback: pull MountOptions into opts initializer · 59d90a47
      Jakob Unterwurzacher authored
      These were open-coded before. Pull them into the struct
      initializer for somewhat clearer code.
      
      I'm doing this now as I'm about to add another option.
      
      Change-Id: Ie04cfc9fb1f4128b8faf5c85757d7263aa77e5a0
      59d90a47