-
Notifications
You must be signed in to change notification settings - Fork 35
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
Canonical method to find backing filesystem (and block device) #280
Comments
mount ids are per namespace though, aren't they, so also not ideal? |
One place where we can encode something is the lower dir mountpoint (i.e. where we mount the erofs), because this is not really visible in the root namespace.
We could easily change the filename of /run/ostree/.private/cfsroot-lower to something that e.g. encodes the major/minor of the backing device. Or we can set an xattr on this file, it is only a mountpoint after all, not the eorfs mount. |
For things like "resize the underlying filesystem", we definitely want the filesystem. In theory I think we can, given a block device, try to find the filesystem mounted on it, but that's obviously ugly.
Yeah, xattrs on the underlying mount point are probably OK to start, at least they wouldn't "leak" into the mounted fs. So today we support multiple datalowers, probably the xattr should include the device number for all of them. And since we need to serialize to a string, we might as well make it decimal formatted so it can be conveniently prepended with e.g. |
See ostreedev/ostree#2867 (comment) - there's a lot of tooling which wants to find the backing filesystem or block device.
As far as I am aware there is no canonical method to do this. Systemd ends up writing a symlink in
/run
for its volatile root bits, but that's it. I think right now one would need to parse the overlayfs mount options in userspace which seems really fragile.overlayfs itself is super flexible - one can union multiple lower filesystems, etc. However for us...I think what I would say is that the default "backing filesystem" is the one holding the erofs metadata.
What'd be pretty nice is if there was some way to attach arbitrary metadata (like xattrs) to a vfs mount.
Failing that though, what we could do since composefs always requires full privileges to mount (because of the erofs usage) is to just generalize what systemd does a bit and have e.g.
/run/composefs/$something
? Where $something is maybe the kernel mount id? (Though the fact it can be reused is problematic)The text was updated successfully, but these errors were encountered: