On Tue, Jun 25, 2024 at 12:42:14PM +0200, Christian Brauner wrote: > On Mon, Jun 24, 2024 at 03:40:49PM GMT, Josef Bacik wrote: > > Hello, > > > > Currently if you want to get mount options for a mount and you're using > > statmount(), you still have to open /proc/mounts to parse the mount options. > > statmount() does have the ability to store an arbitrary string however, > > additionally the way we do that is with a seq_file, which is also how we use > > ->show_options for the individual file systems. > > > > Extent statmount() to have a flag for fetching the mount options of a mount. > > This allows users to not have to parse /proc mount for anything related to a > > mount. I've extended the existing statmount() test to validate this feature > > works as expected. As you can tell from the ridiculous amount of silly string > > parsing, this is a huge win for users and climate change as we will no longer > > have to waste several cycles parsing strings anymore. > > > > This is based on my branch that extends listmount/statmount to walk into foreign > > namespaces. Below are links to that posting, that branch, and this branch to > > make it easier to review. > > So I was very hesitant to do it this way because I feel this is pretty > ugly dumping mount options like that but Karel and others have the same > use-case that they want to retrieve it all via statmount() (or another > ID-based system call) so I guess I'll live with this. But note that this > will be a fairly ugly interface at times. For example, mounting overlayfs with > 500 lower layers then what one gets is: > Yeah this isn't awesome, but neither is the string parsing code I have in the selftest to validate this feature. I chose this approach because 1) it's simple and I'm lazy, and 2) I think anything else becomes a lot more complicated and more work than what people actually want. I imagine what would be ideal would be some sort of mount option iterator mechanism. Either we shoe-horn it into statmount() or we add a listmountoptions() syscall, and we then get back a list of mount options individually laid out. This means we now have to keep track of where we are in our mount option traversal, and change all the ->show_options callbacks to handle this new iter thing. We could go this way I suppose, but again this is a lot of work, and honestly I just want to log mount options into some database so I can go looking for people doing weird shit on my giant fleet of machines/containers. Would the iter thing make the overlayfs thing better? Yeah for sure. Do we care? I don't think so, we just want all the options, and we can all strsep/strtok with a comma. Thanks, Josef
