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
Fix GCI mounter issue #38124
Fix GCI mounter issue #38124
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -130,13 +130,21 @@ func GetMountRefs(mounter Interface, mountPath string) ([]string, error) { | |
} | ||
} | ||
|
||
// TODO: this is a workaround for the unmount device issue caused by gci mounter. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a total hack. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We discussed a few options, but they are all seem hacky... |
||
// In GCI cluster, if gci mounter is used for mounting, the container started by mounter | ||
// script will cause additional mounts created in the container. Since these mounts are | ||
// irrelavant to the original mounts, they should be not considered when checking the | ||
// mount references. Current solution is to filter out those mount paths that contain | ||
// the string of original mount path. | ||
// Plan to work on better approach to solve this issue. | ||
|
||
// Find all references to the device. | ||
var refs []string | ||
if deviceName == "" { | ||
glog.Warningf("could not determine device for path: %q", mountPath) | ||
} else { | ||
for i := range mps { | ||
if mps[i].Device == deviceName && mps[i].Path != slTarget { | ||
if mps[i].Device == deviceName && !strings.Contains(mps[i].Path, slTarget) { | ||
refs = append(refs, mps[i].Path) | ||
} | ||
} | ||
|
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 are you making this change?
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.
otherwise, it only run gc once.
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 is that a problem?
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.
when I test it, I think sometimes the container still in running state in the moment when gc is executed. Give a few try can give more chances to garbage collect the containers . I also thought it was intended to execute 5 times.
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 was only intended to run multiple times if any of the previous attempts fail. Blocking for 5 seconds doesn't sound like a good idea. Is it possible to detect incomplete gc and then retry?
Also why is GC of concern?
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 the container is not GC, it causes those extra mounts which makes
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.
1
might be of concern. Do we have any data to back up that concern?I don't get
2
. Why is umount failing if other shared recursive mounts exist? Is theumount
syscall failing or is it our own custom logic?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.
@jingxu97
Can't we fix that logic then? As long as there is no separate mount point with the same device (bind mount), we can safely unmount. Check the mount reference number in
/proc/self/mountinfo
to make that decision.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 a mount appears in two locations via a shared mount then
/proc/self/mountinfo
will explicitly indicate that. Here is an example.Look at the mount propagation type followed by a propagation number. If the number is the same, then that mount can be ignored. A umount from any one of those paths will result in the mount disappearing from both locations.
$ sudo umount /tmp/original/tmpfs vishnuk@vishnuk-linux:~$ cat /proc/self/mountinfo ...
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.
The current solution used here is checking the mount path and the shared mount path created by the rkt container. If the shared mount path contains the original mount path, this will be filtered out during GetMountRef. See comments #38124 (comment)