You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Atelet should not carve durable data from FULL snapshot when suspending a paused actor #1846
When a paused actor is suspended with onPause: FULL and onCommit: DATA, atelet takes the FULL pause snapshot and uploads only durable-dir.tar from it as the DATA snapshot.
To do that, atelet has to know the file name both ateoms write, this could leave a time bomb for the future if we change the pattern ateom writes sometime.
If atelet wants a DATA snapshot, it should take a DATA snapshot, instead of reusing the FULL snapshot and extracting from it.
We can use --path flag in fscheckpoint to specify which fs to snapshot. If nothing is specified it only snapshots rootfs delta.
However, the approach taken here is to make durableDir as bind mounts and tar the filesystems. To do that we have to pause and then tar the durableDir. We need not take the full snapshot if only data snapshot is required.
Thanks nybidari. To summarize what you mentioned offline: The lifecycle v2 design doesn't need durable-dir's tar/untar anymore, and gVisor can use fscheckpoint for the volumes instead. That would remove the carving this issue is about.
For tracking:
Is this planned for the current milestone? I am still not sure if lifecycle v2 is scoped before GA Dmitry Berkovich (@dberkov).
As part of the lifecycle v2 this part needs to be redesigned.
We are not going to have separate methods for pause and suspended with different behavior anymore.
It will be one method and it will take one kind of snapshot (either l 3 layers or 2 layers on one layer)
Those can still be built in the same internal fundamentals though. We should fix this, even if in short term gvisor needed to take a full snapshot, it can be an internal implementation detail. uVM could just pause the sandbox for consistency and grab the files or something.
And either way, we really should not share knowledge of how durabledur is implemented, the ateom can pass along only the relevant files in the RPC list so atelet does not need to know.
I'm rethinking having atelet in the middle following #1689 but that's a bigger change for later.
Activity
HavenXia commentedon Sep 24, 2026
nybidari do you know if gvisor can take a file system specific snapshot?
I remembered someone told me that is being worked on before.
nybidari commentedon Sep 24, 2026
yes, we can take a filesystem specific snapshot using the fscheckpoint command:
substrate/cmd/ateom-gvisor/runsc.go
Line 177 in d7d7042
We can use
--pathflag in fscheckpoint to specify which fs to snapshot. If nothing is specified it only snapshots rootfs delta.However, the approach taken here is to make durableDir as bind mounts and tar the filesystems. To do that we have to pause and then tar the durableDir. We need not take the full snapshot if only data snapshot is required.
HavenXia commentedon Sep 25, 2026
Thanks nybidari. To summarize what you mentioned offline: The lifecycle v2 design doesn't need
durable-dir's tar/untar anymore, and gVisor can usefscheckpointfor the volumes instead. That would remove the carving this issue is about.For tracking:
dberkov commentedon Sep 25, 2026
As part of the lifecycle v2 this part needs to be redesigned.
We are not going to have separate methods for pause and suspended with different behavior anymore.
It will be one method and it will take one kind of snapshot (either l 3 layers or 2 layers on one layer)
BenTheElder commentedon Sep 28, 2026
Those can still be built in the same internal fundamentals though. We should fix this, even if in short term gvisor needed to take a full snapshot, it can be an internal implementation detail. uVM could just pause the sandbox for consistency and grab the files or something.
And either way, we really should not share knowledge of how durabledur is implemented, the ateom can pass along only the relevant files in the RPC list so atelet does not need to know.
I'm rethinking having atelet in the middle following #1689 but that's a bigger change for later.
HavenXia commentedon Oct 1, 2026
The behavior has been fixed in #2028, now the data snapshot files are returned as response from ateom to atelet instead.
atelet: take the DATA snapshot file set from ateom (agent-substrate#2028