-
Notifications
You must be signed in to change notification settings - Fork 206
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: implement takeover
for nydusd fusedev daemon
#1434
Conversation
As this patch depend on the cloud-hypervisor/fuse-backend-rs#149 , |
@ccx1024cc Can we test the compatibility with the internal nydus implementation? |
Codecov Report
@@ Coverage Diff @@
## master #1434 +/- ##
==========================================
- Coverage 46.41% 46.20% -0.21%
==========================================
Files 123 127 +4
Lines 38745 39033 +288
Branches 38745 39033 +288
==========================================
+ Hits 17983 18036 +53
- Misses 19789 20024 +235
Partials 973 973
|
2a8ab23
to
ed7df0c
Compare
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 <loheagn@icloud.com> Signed-off-by: linan.loheagn3 <linan.loheagn3@bytedance.com>
Thanks for the nice job! Can this work with the nydus-snapshotter ? I also have plans to support takeover feature for fscache mode, I think there are some process that can be reused. |
.session | ||
.lock() | ||
.unwrap() | ||
.get_fuse_file() |
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.
If nydusd exit when there are inflight fuse requests, IO hung occurs because the mainline kernel does not support resending inflight fuse requests. If we want to support takeover for fusedev, how about store the fuse fd created by ioctl FUSE_DEV_IOC_CLONE, then when nydusd exit, the inflight requests will be dropped instead of blocking IO.
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.
Get.
How about implementing this function which clones the fuse fd in fuse-backend-rs crate? For example, add a method named clone_fuse_file
to FuseSession
?
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.
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.
Maybe make it as a built-in feature in fuse-backend-rs
? WDYT cc @jiangliu ?
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.
Sure, let's get fuse-backend-rs ready for this:)
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.
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.
cloud-hypervisor/fuse-backend-rs#177 may fix this
Here is a pr containerd/nydus-snapshotter#520 for nydus-snapshotter to do failover and hot upgrade. This pr adds some check code to ensure the upgrade process be done for all the old version nydus daemons, especially the deamons created during the upgrade stage. I have tested the failover feature and more test cases should be added. |
As I know , the nydus-snapshotter already support failover and hot upgrade workflow. |
I will send another pr also support takeover for fscache , which fold your patch , then we can start reviewing full takeover feature. |
@kevinXYin The feature has been pending for too long. Let's do it step by step, by merging the fuse takeover first, and then you can proceed with fscache takeover. |
@bergwolf #1487 has already contain the commits in this pr. This pr can be closed. |
Relevant Issue (if applicable)
#1421
Details
This patch implements the
save
andrestore
functions in thefusedev_upgrade
in the service crate.To do this,
nydus-upgrade
into the workspace. Thenydus-upgrade
crate 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 namedStorageBackend
which can be used to store and restore fuse session fds and state data for the upgrade action, and there's also an implementation namedUdsStorageBackend
which uses unix domain socket to do this.FusedevState
to hold these information. TheFusedevState
is serialized and stored into theUdsStorageBackend
(which happens in thesave
function in thefusedev_upgrade
module) before the new daemon is created, and theFusedevState
is deserialized and restored from theUdsStorageBackend
(which happens in therestore
function in thefusedev_upgrade
module) when the new daemon is triggered bytakeover
.Types of changes
Checklist
Go over all the following points, and put an
x
in all the boxes that apply.