-
Notifications
You must be signed in to change notification settings - Fork 205
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
implement takeover
for nydus fscache/fusedev mode
#1487
Conversation
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.
Smoke test is required.
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #1487 +/- ##
==========================================
- Coverage 62.82% 62.72% -0.11%
==========================================
Files 125 129 +4
Lines 43599 44158 +559
Branches 43599 44158 +559
==========================================
+ Hits 27391 27698 +307
- Misses 14854 15092 +238
- Partials 1354 1368 +14
|
This patch implements the `save` and `restore` functions in the `fusedev_upgrade` in the service create. To do this, - This patch add a new create named `nydus-upgrade` into the workspace. The `nydus-upgrade` create has some util functions help to do serialization and deserialization for the rust structs using the versionize and snapshot crates. The crate also has a trait named `StorageBackend` which can be used to store and restore fuse session fds and state data for the upgrade action, and there's also an implementation named `UdsStorageBackend` which uses unix domain socket to do this. - as we have to use the same fuse session connection, backend file system mount commands, Vfs to re-mount the rafs for the new daemon (created for "hot upgrade" or failover), this patch add a new struct named `FusedevState` to hold these information. The `FusedevState` is serialized and stored into the `UdsStorageBackend` (which happens in the `save` function in the `fusedev_upgrade` module) before the new daemon is created, and the `FusedevState` is deserialized and restored from the `UdsStorageBackend` (which happens in the `restore` function in the `fusedev_upgrade` module) when the new daemon is triggered by `takeover`. Signed-off-by: Nan Li <[email protected]> Signed-off-by: linan.loheagn3 <[email protected]>
2bb9a7c
to
c7ed6f0
Compare
a8ce6f9
to
2b0a2a6
Compare
takeover
for nydus fscache modetakeover
for nydus fscache/fusedev mode
9426322
to
abbf2d9
Compare
Otherwise LGTM, thanks for the great work:) |
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.
Thanks for the work, let's add a smoke test case for validating fusedev failover later cc @loheagn .
refine the UpgradeManager, make it can also support store status for fscache daemon. And make the takeover feature applies to both fuse and fscache mode. Signed-off-by: Xin Yin <[email protected]>
Signed-off-by: Xin Yin <[email protected]>
Signed-off-by: Xin Yin <[email protected]>
Relevant Issue (if applicable)
#1421
Details
This is based on #1434 , make the takeover feature can support both fusedev and fscache mode.
Types of changes
What types of changes does your PullRequest introduce? Put an
x
in all the boxes that apply:Checklist
Go over all the following points, and put an
x
in all the boxes that apply.