Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

range invalidate to grow file sees zero content #237

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

range invalidate to grow file sees zero content #237

tv42 opened this issue Oct 1, 2015 · 3 comments
Assignees
Milestone

Comments

@tv42
Copy link

@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
Copy link
Member

@bfleischer 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
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
Copy link
Member

@bfleischer 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
Copy link
Author

@tv42 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
…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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.