range invalidate to grow file sees zero content #237

Closed
tv42 opened this Issue Oct 1, 2015 · 3 comments

Comments

Projects
None yet
2 participants
@tv42

tv42 commented Oct 1, 2015

This bug happens with OSXFUSE 3.0.6.

grow.go is a filesystem with a single file, hello. The initial
contents of the file are hello, world\n. 5 seconds after it has been
read, it grows by appending goodbye\n, and sending an invalidation
(offset=13, size=8). Future reads will see hello, world\ngoodbye\n.

Here's a sample session from Linux:

$ cat mnt/hello
hello, world
$ cat mnt/hello
hello, world
goodbye

Here's the observed behavior on OSXFUSE 3.0.6:

$ cat mnt/hello
hello, world
$ cat mnt/hello
hello, world
$ cat mnt/hello|hexdump -C
00000000  68 65 6c 6c 6f 2c 20 77  6f 72 6c 64 0a 00 00 00  |hello, world....|
00000010  00 00 00 00 00                                    |.....|
00000015

This seems to be related specifically to range invalidations. If I
invalidate all of the data (offset=0, size=-1), I see the correct
contents.

As you can see from the debug logs, there are no Read calls seen
after the invalidation; OSXFUSE thinks the cache contents are valid.

Extra files at https://gist.github.com/tv42/699e01290ad91f5903e7

@bfleischer

This comment has been minimized.

Show comment
Hide comment
@bfleischer

bfleischer Oct 1, 2015

Member

Thanks for the bug report. The problem seem to be that the last page in the ubc cache (before extending the file) is not invalidated automatically when extending the file. This page contains "hello world\n" and is padded with zeros.

If farewell is greater than 4 KB the ubc cache allocates a second page and another read request is issued for that page.

Member

bfleischer commented Oct 1, 2015

Thanks for the bug report. The problem seem to be that the last page in the ubc cache (before extending the file) is not invalidated automatically when extending the file. This page contains "hello world\n" and is padded with zeros.

If farewell is greater than 4 KB the ubc cache allocates a second page and another read request is issued for that page.

bfleischer added a commit to osxfuse/kext that referenced this issue Oct 2, 2015

Fix invalidation error in fuse_notify_getattr
Unless the file did end on a page boundary we need to invalidate the
last page of the file's unified buffer cache maunally. ubc_setsize
does not take care of this when expanding files.

See osxfuse/osxfuse#237 for details.
@bfleischer

This comment has been minimized.

Show comment
Hide comment
@bfleischer

bfleischer Oct 2, 2015

Member

Please check again with the following build. Unless the file ends on a page boundary the new build will invalidate the last page of the file's unified buffer cache (before expanding the file). This fixes the issue for me. In my opinion it is kind of odd that the kernel invalidates the last page when shrinking files but not when expanding files.

https://www.dropbox.com/s/5gsfzh6c98dq04d/osxfuse-3.0.6_1.dmg?dl=0

Member

bfleischer commented Oct 2, 2015

Please check again with the following build. Unless the file ends on a page boundary the new build will invalidate the last page of the file's unified buffer cache (before expanding the file). This fixes the issue for me. In my opinion it is kind of odd that the kernel invalidates the last page when shrinking files but not when expanding files.

https://www.dropbox.com/s/5gsfzh6c98dq04d/osxfuse-3.0.6_1.dmg?dl=0

@bfleischer bfleischer self-assigned this Oct 2, 2015

@tv42

This comment has been minimized.

Show comment
Hide comment
@tv42

tv42 Oct 2, 2015

That one passes the test, thanks!

tv42 commented Oct 2, 2015

That one passes the test, thanks!

@bfleischer bfleischer closed this Oct 2, 2015

@bfleischer bfleischer added this to the 3.0.7 milestone Nov 10, 2015

strib pushed a commit to keybase/kbfs that referenced this issue May 26, 2016

Revert "libfuse: work around osxfuse bug by always invalidating all d…
…ata"

This reverts commit e2be6410b85f28f9458f4eab954b1dd0182e1a94.

osxfuse/osxfuse#237 was fixed by OSXFUSE 3.0.7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment