-
Notifications
You must be signed in to change notification settings - Fork 34
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
feat: use squashfuse ready notifier if available #528
Conversation
baf4d85
to
cdd4833
Compare
Codecov Report
@@ Coverage Diff @@
## main #528 +/- ##
==========================================
- Coverage 13.34% 13.14% -0.21%
==========================================
Files 40 40
Lines 5852 5943 +91
==========================================
Hits 781 781
- Misses 4943 5034 +91
Partials 128 128
... and 5 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
Is it actually less reliable? I agree that responding to an event is nicer than polling, but have we actually found polling to be "unreliable"? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this looks sane.
It'd be nice if we could only check once (sync.Once) for presense of squashfuse executable and also whether or not it has notify pipe support.
I don't think its a blocker (we're currently checking squashfuse every time) but would be nice.
These were Serge's words, @hallyn do you have any comments? |
Well, |
yeah, i'd be fine with that. and it can just store the result in a global type squashfuse struct {
Path string
Version version
notfiy bool
} oir something like that. |
And initialize this struct only once? Then, for subsequent calls to the findSquashfusePath function, just return the global struct? |
Yes. Because it checks inode version of the root dentry, I have seen cases where, when already inside an overlayfs, the mount hung because the dentry info never appeared to change. At least, I think that's what I saw :) Writing a reliable reproducer of that would be kind of nifty. |
Right, if you initialize it in a sync.Once, it'll automatically just happen once. |
@smoser @ariel-miculas it appears that every overlay mount's root dentry shows a different 'device' in stat(), and that's enough for os.SameFile() to do the right thing. So the only advantage here is not waiting (not waiting too long, and not risking timeing out too soon). I still think that's worthwhile. But there may not be a correctness issue as I thought there was. |
@hallyn what does overlay have to do with squashfuse? |
cdd4833
to
24d726b
Compare
Right you are, I was confusing myself. But just mounting two squashfuse's and stat()ing the root dentry still gives me different device ids. |
24d726b
to
e79ca9e
Compare
When using squasfuse, check whether it supports -o notifypipe. If it does, use it instead our manual checking of the mountpoint inode. The notification mechanism is a better alternative to the existing polling approach. If it's not available, then use the old mechanism. This feature is supported starting from squasfuse version 0.5.0, see [1] for details. [1] vasi/squashfuse#49 Co-Developed-by: Serge Hallyn <serge@hallyn.com> Signed-off-by: Ariel Miculas <amiculas@cisco.com>
e79ca9e
to
6857ed5
Compare
@smoser, does the PR look good to you now? |
When using squasfuse, check whether it supports -o notifypipe. If it does, then use that instead of our manual checking the mountpoint inode, which is less reliable.
Co-Developed-by: Serge Hallyn serge@hallyn.com
See previous PR
Changes compared to the original PR:
This is a new PR because I cannot amend Serge's original PR.
What type of PR is this?
feature
Which issue does this PR fix:
none
What does this PR do / Why do we need it:
It uses the newly available squashfuse notification mechanism.
If an issue # is not available please add repro steps and logs showing the issue:
Testing done on this change:
Tested with the following program:
Output:
The first time it succeeds and the second time it fails, since the fuse mountpoint already exists.
With stacker:
Old squashfuse (<0.5.0)
Note that the overlay fails, but the squashfuse mounts have been created:
New squashfuse (>=0.5.0)
Note that the overlay fails, but the squashfuse mounts have been created:
Automation added to e2e:
Will this break upgrades or downgrades?
No
Does this PR introduce any user-facing change?:
No
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.