starred/s3fs-fuse

Fork 0

mirror of https://github.com/s3fs-fuse/s3fs-fuse.git synced 2026-04-25 21:35:58 +03:00

[GH-ISSUE #1062] investigate macOS integration test workarounds #583

New issue

Closed

opened 2026-03-04 01:46:57 +03:00 by kerem · 7 comments

kerem commented

2026-03-04 01:46:57 +03:00

Owner

Originally created by @gaul on GitHub (Jun 30, 2019).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/1062

Several tests including test_append_file have a suspicious workaround:

    if [ `uname` = "Darwin" ]; then
       cat /dev/null > ${TEST_TEXT_FILE}
    fi

Without it s3fs returns stale metadata from the stat cache. Comparing logs confuses me but it appears that the flush happens later than on Linux. @ggtakec do you have any idea why this is necessary?

Originally created by @gaul on GitHub (Jun 30, 2019). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/1062 Several tests including `test_append_file` have a suspicious workaround: ```sh if [ `uname` = "Darwin" ]; then cat /dev/null > ${TEST_TEXT_FILE} fi ``` Without it s3fs returns stale metadata from the stat cache. Comparing logs confuses me but it appears that the flush happens later than on Linux. @ggtakec do you have any idea why this is necessary?

kerem closed this issue

2026-03-04 01:46:57 +03:00

kerem commented

2026-03-04 01:46:58 +03:00

Author

Owner

@ggtakec commented on GitHub (Jul 16, 2019):

@gaul It was a code added by #630 PR.
At this time, maybe I added it to pass OSX tests, but this may have hidden the bug.
If you cut this code now, will it not cause an error on OSX?
If errors occur, I will try to investigate.
If it does not occur, we should remove this code immediately.

@ggtakec commented on GitHub (Jul 16, 2019): @gaul It was a code added by #630 PR. At this time, maybe I added it to pass OSX tests, but this may have hidden the bug. If you cut this code now, will it not cause an error on OSX? If errors occur, I will try to investigate. If it does not occur, we should remove this code immediately.

kerem commented

2026-03-04 01:46:58 +03:00

Author

Owner

@gaul commented on GitHub (Jul 16, 2019):

Removing these causes the tests to fail. I looked into this but I don't understand the failure.

@gaul commented on GitHub (Jul 16, 2019): Removing these causes the tests to fail. I looked into this but I don't understand the failure.

kerem commented

2026-03-04 01:46:58 +03:00

Author

Owner

@ggtakec commented on GitHub (Aug 1, 2019):

I remembered this reason, I think this depends on the behavior of osxfuse.
I did not pass the test(test_external_modification) at hand now, then I investigated and remembered.

The test fails if the file is written and read immediately after startup s3fs. This is because s3fs_read() handler is not called by osxfuse.

You can do same issue:

$ echo "test1" > s3fs-integration-test/testfile
$ cat s3fs-integration-test/testfile            <--- something wrong(empty)
$ echo "test2" > s3fs-integration-test/testfile
$ cat s3fs-integration-test/testfile            <--- ok
  test2

This seems to be related to the handling of "struct fuse_file_info * fi" inside osxfuse, but the details are unknown.
Issues that seem to be related: https://github.com/osxfuse/osxfuse/issues/203

Now I read and write only once to avoid this(cat /dev/null > file).
However, this workaround is not good, so we need to find a way to escape this(or osxfuse issue).

@ggtakec commented on GitHub (Aug 1, 2019): I remembered this reason, I think this depends on the behavior of osxfuse. I did not pass the test(test_external_modification) at hand now, then I investigated and remembered. The test fails if the file is written and read immediately after startup s3fs. This is because s3fs_read() handler is not called by osxfuse. You can do same issue: ``` $ echo "test1" > s3fs-integration-test/testfile $ cat s3fs-integration-test/testfile <--- something wrong(empty) $ echo "test2" > s3fs-integration-test/testfile $ cat s3fs-integration-test/testfile <--- ok test2 ``` This seems to be related to the handling of "struct fuse_file_info * fi" inside osxfuse, but the details are unknown. Issues that seem to be related: https://github.com/osxfuse/osxfuse/issues/203 Now I read and write only once to avoid this(cat /dev/null > file). However, this workaround is not good, so we need to find a way to escape this(or osxfuse issue).

kerem commented

2026-03-04 01:46:58 +03:00

Author

Owner

@ggtakec commented on GitHub (Aug 3, 2019):

@gaul
In the case of osxfuse, it seems that read system call is not called when it is cached (by OS or fuse).
I could not find the same phenomenon with libfuse for linux.

The explanation of fuse (osxfuse) is as follows.

if kernel_cache option is not specified and neither direct_io, 
data is still cached after the open(2), so a read(2) system call 
will not always initiate a read operation.

So I tried the kernel_cache and direct_io options and confirmed that the read system call was called.
Note that if user specify the kernel_cache option, when user change the file from the outside (by the aws command etc.), the change can not be detected.
In other words, in the case of osx, I think that the problem can be avoided by attaching direct_io.

As a result, it has not been measured how much the system calls will increase and how much the performance will decrease.
However, it is necessary to pass test_external_modification tests and other tests with osx.

If there is no problem, I delete the indicated branch statement of test_append_file test, change travis.yaml, and send PR.

@ggtakec commented on GitHub (Aug 3, 2019): @gaul In the case of osxfuse, it seems that read system call is not called when it is cached (by OS or fuse). I could not find the same phenomenon with libfuse for linux. The explanation of fuse (osxfuse) is as follows. ``` if kernel_cache option is not specified and neither direct_io, data is still cached after the open(2), so a read(2) system call will not always initiate a read operation. ``` So I tried the `kernel_cache` and` direct_io` options and confirmed that the read system call was called. Note that if user specify the `kernel_cache` option, when user change the file from the outside (by the aws command etc.), the change can not be detected. In other words, in the case of osx, I think that the problem can be avoided by attaching `direct_io`. As a result, it has not been measured how much the system calls will increase and how much the performance will decrease. However, it is necessary to pass test_external_modification tests and other tests with osx. If there is no problem, I delete the indicated branch statement of test_append_file test, change travis.yaml, and send PR.

kerem commented

2026-03-04 01:46:58 +03:00

Author

Owner

@ggtakec commented on GitHub (Aug 6, 2019):

By specifying the direct_io option, this unnecessary code could be removed.

However, when using osxfuse 3.8.0 or earlier, direct_io causes a problem with append redirect.
For this reason, brew needs to be updated in osx tests.
As a result, the osx test time exceeds 12 minutes.
This is reflected in the PR of #1119.

@ggtakec commented on GitHub (Aug 6, 2019): By specifying the direct_io option, this unnecessary code could be removed. However, when using osxfuse 3.8.0 or earlier, direct_io causes a problem with append redirect. For this reason, brew needs to be updated in osx tests. As a result, the osx test time exceeds 12 minutes. This is reflected in the PR of #1119.

kerem commented

2026-03-04 01:46:58 +03:00

Author

Owner

@ggtakec commented on GitHub (Aug 6, 2019):

Since test_read_external_object test still fails in osx, add auto_cache( #1120 ) option in addition to direct_io.

@ggtakec commented on GitHub (Aug 6, 2019): Since test_read_external_object test still fails in osx, add auto_cache( #1120 ) option in addition to direct_io.

kerem commented

2026-03-04 01:46:58 +03:00

Author

Owner

@ggtakec commented on GitHub (Aug 6, 2019):

This issue-related PR has been merged earlier in order to pass other PRs and tests without problems.
If there is a problem with the correction, please let me know.

@ggtakec commented on GitHub (Aug 6, 2019): This issue-related PR has been merged earlier in order to pass other PRs and tests without problems. If there is a problem with the correction, please let me know.

kerem referenced this issue

2026-03-04 02:01:02 +03:00

[PR #583] [MERGED] Updated limit object size in s3fs man page #1557