search

jacobsa / fuse

A Go package for implementing a FUSE file system.
Apache License 2.0
478 stars 106 forks source link

FUSE-T macOS support #146

Closed macos-fuse-t closed 6 months ago

macos-fuse-t commented 12 months ago

FUSE-T is a user space implementation of FUSE for macOS which doesn't require kernel extensions (KEXT) More details at https://github.com/macos-fuse-t/fuse-t

macos-fuse-t commented 11 months ago

Thanks for your PR.

I can’t find the source of fuse-t anywhere? Are you offering to take care of user-reported issues with fuse-t in this repository?

Yes, I will take care of any user-reported issues related to fuse-t. fuse-t behaves a little bit different than conventional fuse, some minor features won't work correctly by virtue of being implemented over NFS but the benefits over osxfuse are significant

stapelberg commented 8 months ago

Sorry for letting this PR linger for so long — the last few months have been very busy. I’ll try to return to it soon.

sethiay commented 2 months ago

Hey @macos-fuse-t jacobsa/fuse is used in GCSFuse as well and we recently observed read performance regressions due to this commit. We tried locally removing this lock and that helped solve the regression.

Could you please revisit your commit and help in fixing this regression ? We are blocked on upgrading the jacobsa/fuse dependency in GCSFuse because of this.

E.g. regression image

macos-fuse-t commented 2 months ago

@sethiay As I stated previously writev() function is not atomic (at least not on macOS), meaning you get unpredictable results if there are several concurrent writev() calls. I suppose the regression is on Linux? Are you sure that it happens consistently because the lock looks quite innocuous. Perhaps the lock should be limited to macOS only if the regression is real. Would you mind to tell me how do you test so I can try to reproduce it myself?

sethiay commented 2 months ago

@macos-fuse-t

@sethiay As I stated previously writev() function is not atomic (at least not on macOS), meaning you get unpredictable results if there are several concurrent writev() calls.

I think you are talking about exclusion of one writev call from the other call for consistency and not atomicity. Also, the locks being added doesn't affect the atomicity of writev call. I am also not sure about consistency guarantees and found this on web: https://unix.stackexchange.com/questions/341050/im-wondering-how-the-atomicity-of-writev-is-ensured. Also, before this PR, without the writeLocks, we (GCSFuse) haven't received any consistency issues.

I suppose the regression is on Linux?

Yes

Are you sure that it happens consistently because the lock looks quite innocuous. Perhaps the lock should be limited to macOS only if the regression is real.

Yes, I ran the performance tests multiple times before flagging this issue.

Would you mind to tell me how do you test so I can try to reproduce it myself?

I don't have a minimal reproducer for the tests. However, I can explain the tests - The test runs 40 threads concurrently on a n2-standard 32 CPU cores Google Compute Engine VM where each thread continuously reads different 50MB file from a FUSE filesystem implementing jacobsa/fuse's filesystem interface for 60s.

sethiay commented 2 months ago

@macos-fuse-t Did yo get chance to look into the response ?

macos-fuse-t commented 2 months ago

@sethiay I'm looking into it. I'll try to send you a workaround to test. Please be patient because I'm a bit busy right now

stapelberg commented 1 month ago

I don’t want to be too pushy, but could you provide a rough timeline estimate? Are we talking days, weeks, months?

I’m asking because @sethiay and team are eager to pick up https://github.com/jacobsa/fuse/commit/84480b28de63de1527052448f9b8fdd3ff6cbd33, which was submitted after the macOS changes.

If fixing this regression takes a few weeks, it might be best to revert the macOS changes for now and re-submit them later.

Thanks

macos-fuse-t commented 1 month ago

I'll try to send a PR until the end of the week.