Open cgwalters opened 3 months ago
mount ids are per namespace though, aren't they, so also not ideal? Do you really need the filesystem, or is the minor+major of the block device enough?
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. For example, this is how an ostree rootfs looks in /proc/mounts:
overlay / overlay ro,seclabel,relatime,lowerdir=/run/ostree/.private/cfsroot-lower::/sysroot/ostree/repo/objects,redirect_dir=on,verity=require,metacopy=on 0 0
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.
Do you really need the filesystem, or is the minor+major of the block device enough?
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.
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.
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. /sys/dev/block
.
See https://github.com/ostreedev/ostree/issues/2867#issuecomment-2108090355 - 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)