Functions `GetMounts()` and `parseMountTable()` return all the entries
as read and parsed from /proc/self/mountinfo. In many cases the caller
is only interested only one or a few entries, not all of them.
One good example is `Mounted()` function, which looks for a specific
entry only. Another example is `RecursiveUnmount()` which is only
interested in mount under a specific path.
This commit adds `filter` argument to `GetMounts()` to implement
two things:
1. filter out entries a caller is not interested in
2. stop processing if a caller is found what it wanted
`nil` can be passed to get a backward-compatible behavior, i.e. return
all the entries.
A few filters are implemented:
- `PrefixFilter`: filters out all entries not under `prefix`
- `SingleEntryFilter`: looks for a specific entry
Finally, `Mounted()` is modified to use `SingleEntryFilter()`, and
`RecursiveUnmount()` is using `PrefixFilter()`.
Unit tests are added to check filters are working.
[v2: ditch NoFilter, use nil]
[v3: ditch GetMountsFiltered()]
[v4: add unit test for filters]
[v5: switch to gotestyourself]
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: bb934c6aca3e77541dd4fd51b9ab2706294dadda
Component: engine
Sorting by mount point length can be implemented in a more
straightforward fashion since Go 1.8 introduced sort.Slice()
with an ability to provide a less() function in place.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: a00310b54c0cdcafb402aeea92feca865da9fdf3
Component: engine
When a recursive unmount fails, don't bother parsing the mount table to check
if what we expected to be a mountpoint is still mounted. `EINVAL` is
returned when you try to unmount something that is not a mountpoint, the
other cases of `EINVAL` would not apply here unless everything is just
wrong. Parsing the mount table over and over is relatively expensive,
especially in the code path that it's in.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: dd2108766017c13a19bdbfd1a56cd1358580e0bb
Component: engine
Before this, if `forceRemove` is set the container data will be removed
no matter what, including if there are issues with removing container
on-disk state (rw layer, container root).
In practice this causes a lot of issues with leaked data sitting on
disk that users are not able to clean up themselves.
This is particularly a problem while the `EBUSY` errors on remove are so
prevalent. So for now let's not keep this behavior.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 54dcbab25ea4771da303fa95e0c26f2d39487b49
Component: engine
This fixes issues where the underlying filesystem may be disconnected and
attempting to unmount may cause a hang.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: acbfe6bc56b9357d40a452f6b3901cb2c2d40404
Component: engine
Fix the following warnings:
pkg/mount/mountinfo.go:5:6: type name will be used as mount.MountInfo by other packages, and that stutters; consider calling this Info
pkg/mount/mountinfo.go:7:2: struct field Id should be ID
Signed-off-by: Antonio Murdaca <runcom@linux.com>
Upstream-commit: 0f5c9d301b9b1cca66b3ea0f9dec3b5317d3686d
Component: engine
Without this line of code, if a volume is present in /proc/mounts,
it cannot be remounted with new mount options.
Docker-DCO-1.1-Signed-off-by: Peter Waller <p@pwaller.net> (github: pwaller)
Upstream-commit: f87afda12344b726c1bfb49b2dc8b5995f86f4ab
Component: engine
Mount is self contained and generic, it should be in pkg, to allow other pkg modules to use it.
Docker-DCO-1.1-Signed-off-by: Paul Nasrat <pnasrat@gmail.com> (github: pnasrat)
Upstream-commit: 2e094db6390dde57263c07665290b1477bb6df7e
Component: engine
Kir Kolyshkin
Daniel Nephin
Brian Goff
Yong Tang
Kenfe-Mickael Laventure
unclejack
Amit Krishnan
Antonio Murdaca
Jamie Hannaford
Peter Waller
Paul Nasrat