-
Notifications
You must be signed in to change notification settings - Fork 103
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
Fscache gc #262
Fscache gc #262
Conversation
Codecov ReportBase: 31.57% // Head: 31.38% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #262 +/- ##
==========================================
- Coverage 31.57% 31.38% -0.20%
==========================================
Files 34 34
Lines 3506 3518 +12
==========================================
- Hits 1107 1104 -3
- Misses 2283 2298 +15
Partials 116 116
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
query.Add("blob_id", blobID) | ||
} | ||
} else { | ||
query.Add("blob_id", blobID) |
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.
Can we have a comment describing the blob id and domain id combination here or a UT test? Otherwise, it is hard to maintain
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.
Yeah , will add comment after the API fixed
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.
As the nydusd API was fixed and merged, shall we have a description comments now?
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.
We have to consider the API compatibility here. Old nydusd won't extract "blob_id' from the request, right? So old nydusd still can work with this nydus-snapshotter?
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.
Already add some comment for the API , and this new semantic is just used to delete fscache cache files, if the old nydusd did not support this then snapshotter will just ignore the error and print error info, which is as expectation. so I think we do not need compatible with an old nydusd.
pkg/filesystem/fs/fs.go
Outdated
} | ||
// delete fscache blob cache file | ||
if err := c.UnbindBlob("", blobID); err != nil { | ||
log.L.Warnf("delete blob %s err %s", blobID, err) |
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.
Should return error?
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.
yes , we better return error , but this will cause snapshotter can not forward compatible nydusd?
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.
You are right, perhaps we should let snapshotter nydusd client is aware or nydusd version to workaround
@@ -203,11 +203,17 @@ func NewSnapshotter(ctx context.Context, cfg *config.Config) (snapshots.Snapshot | |||
return nil, err | |||
} | |||
|
|||
syncRemove := cfg.SyncRemove | |||
if cfg.FsDriver == config.FsDriverFscache { | |||
log.L.Infof("for fscache mode enable syncRemove") |
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.
We can not use syncRemove flag to control whether to remove fscache files. Just directly remove it in a goroutine
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.
AKAIK, the syncRemove is used for making removing snapshot in order , cause we need remove bootstrap snapshot first and then we can umount erofs. So should we force enable syncRemove for fscache ?
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.
We can simply make fscache files deletion out of the syncRemove==true if arm
@@ -323,8 +324,9 @@ func (d *Daemon) sharedErofsUmount(rafs *Rafs) error { | |||
return errors.Wrapf(err, "unbind blob %s", d.ID()) | |||
} | |||
domainID := rafs.Annotations[AnnoFsCacheDomainID] | |||
fscaheID := rafs.Annotations[AnnoFsCacheID] |
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.
It's better to handle the absence of fscacheid. Moreover, should the name be consistent? I saw it is named blobID in function UnbindBlob
body
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.
fscacheID will be set with domainID together, it can not be absent. fscacheID will used for generate fscache cookie key for bootstrap, and we need it when delete fscache cache file for bootstrap. Already add comment for this.
// delete fscache bootstrap cache file | ||
if err := c.UnbindBlob("", fscaheID); err != nil { | ||
log.L.Warnf("delete bootstrap %s err %s", fscaheID, err) | ||
} |
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.
Why ignoring the unbind error here?
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.
two reasons for this:
- make compatible with old nydusd.
- Is this need to return err to containerd when delete bootstrap cache failed? seems we do not do this for blob cache
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.
Yes. It's a way to handle compatibility, however, it also hides the error if the nydusd supports this new API. Let's do it this way right now.
Can you please rebase this PR to latest main branch? The base code has changed. It will be easier to view those changes. |
71c0be3
to
ba37249
Compare
pkg/daemon/client.go
Outdated
* 2. domainID + blobID, delete the blob entry, if the blob is bootstrap | ||
* also delete blob entries belong to it. | ||
* 3. blobID, try to find and cull blob cache files by blobID in all domains. | ||
*/ |
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.
Just a nit: //
comment style might match the project comment style
// delete fscache bootstrap cache file | ||
if err := c.UnbindBlob("", fscaheID); err != nil { | ||
log.L.Warnf("delete bootstrap %s err %s", fscaheID, err) | ||
} |
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.
Yes. It's a way to handle compatibility, however, it also hides the error if the nydusd supports this new API. Let's do it this way right now.
6f7fa94
to
8654605
Compare
In fscache shared domain mode, before umount erofs we should call DELETE blob API with domainId + fscacheId. Signed-off-by Xin Yin <[email protected]>
delete fscache cache files for blobs and bootstrap when remove image. Signed-off-by:Xin Yin <[email protected]>
8654605
to
a9145a2
Compare
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.
LGTM
support fscahe gc