Skip to content
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

Open
cgwalters opened this issue May 13, 2024 · 3 comments
Open

Canonical method to find backing filesystem (and block device) #280

cgwalters opened this issue May 13, 2024 · 3 comments

Comments

@cgwalters
Copy link
Contributor

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)

@alexlarsson
Copy link
Collaborator

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?

@alexlarsson
Copy link
Collaborator

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.

@cgwalters
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants