EXT4 Prepared To Switch To Linux's New Mount API

[Saverios]

Does anyone know if this is a "drop-in" replacement for old mount or will we have to change our fstab options?

(Apologies if this is covered in the presentation, I won't have time to view it properly for a while)

[uid313]

i'm not sure how chs or rotating platter affects mount. we had network/fuse/tmpfs mounts for decades

Yeah but maybe the mount syscall was made before network and FUSE.
Maybe FUSE could better if it used this New Mount API.

Maybe back in the days you could just synchronously call mount and it would always succeed and return void, I don't know.
Maybe now, these days you have needs to async mount and it might not be immediate and it might fail.

[oiaohm]

This smells like overengineering.

Really you need to watch the video. I wish this video had the PDF the walk though of the old mount issues are kind of important.

The old mount API is underengineered and has turned into round peg in square hole solution. Yes very quirky and unintuitive.

I agree with you, it is very hard to believe that an extra complexity in the kernel interface will actually make things better.

But o the same note, having more flexibility is not an issue in itself. If they manage to get an "one-shot effort", who uses this new syscalls and do the mounting quickly, for the people who don't need the extra flexibility this can actually be a good thing.

This new mount api set is not designed to be faster. In fact it designed to be slower once you start understand what has gound wrong with the old mount syscall this starts making lots of sense. The old one shot mount command has its problems. Like you cannot send error back when user is technically setting a parameter that no longer exists on a file system without breaking userspace. This explains why people keep on using intr/nointr on nfs mounts even that it was removed from the kernel over a decade ago.

https://access.redhat.com/solutions/157873

April 2008 was went intr/nointr feature was removed and if you are expect the behaviour you are in trouble because it a silent failure. Yes you still see people writing in 2020 for NFS under Linux that intr/nointr works even that it has not for a decade+. Yes this is effect of the old one shot mount and the linux kernel rule do not break user space results in having to just ignore when user sets intr/nointr and they no longer exist with the old mount syscall as there was no way include to send a error back in those case. This is only 1 example but there are is over 100 faults like this.

https://www.kernel.org/doc/html/latest/filesystems/mount_api.html

Parse the parameters and attach them to the context. Parameters are expected to be passed individually from userspace, though legacy binary parameters can also be handled.

Yes this and there is now a option in the mount process to query what parameters are still currently valid to use and give you a error back when you attempt to set a parameter that no longer exists without in fact stopping the mount process from going forwards.

Maybe, or maybe mounting needs to be re-thought from the rotating platter hard disk drives on cylinder-head-sector (CHS) technology in a world that SSD, asynchronous, cached, remote, distributed, and new technology like software-defined storage, etc.

No this is not the problem. Introduction of bind mounts and other things started leading to more and more quirky behaviours.

i'm not sure how chs or rotating platter affects mount. we had network/fuse/tmpfs mounts for decades

You missed name spaces and procfs.... Basically there are a long list of things that were added to Linux since the original mount syscall was design. All those new features have been progressively shoe horned into that mount syscall this is why it come quirky. So yes the original mount syscall is massive under engineered and not at all designed to deal with the modern real world file system complexity.

Yes mount syscall in the Linux kernel was first designed before Linux kernel had a network stack yes right at day one. The thing has done 30 years of service. Everything is way more complex than back then and has truly got to being under engineered for the problem.

This new one could be slightly over engineered and is for sure worse performance but we really don't want mounts to be quirky. Some of the quirks with the old mount syscall really bad like you set bind mount and read only with each other some combinations result in read only not set at all or other cases read only partly set so sections of the bind mount are read/write that the user is not expecting. Some catch a small number of users out like the intr/nointr not existing any more.

[baryluk]

Does anyone know if this is a "drop-in" replacement for old mount or will we have to change our fstab options?

(Apologies if this is covered in the presentation, I won't have time to view it properly for a while)

Do not worry about it. fstab will work just fine for next 100 years.

This is just a new API. The `mount` command will updated to use this kernel API when time is needed.

The new API solves few important problems with the old API, can do everything that the old API does, plus some more (like do a mount per-process, and manipulate parts of vfs, without it being exposed anywhere else). This is really cool. Plus it fixes long standing issue with passing filesystem-specific options to the kernel (i.e. nfs and fuse are notorious for having a lot of weird structs being passed in ugly ways).

[pal666]

Basically there are a long list of things that were added to Linux since the original mount syscall was design.

sure, i was only opposing relevance of chs for mount

[oiaohm]

sure, i was only opposing relevance of chs for mount

Except they were not right but they were not 100 percent wrong either. Early Linux only support chs file systems. No network file systemes/tmpfs/... Yes this time frame is when the early mount syscall was in fact designed then everything from there was shoe horned into it by imperfect means leading to the syscall being quirky.

The mount syscall the old one was designed when Linus Torvalds thought the Linux would never develop into a major OS and only be a toy OS.

chs bit is a correlation basically that the early file systems that mount syscall was designed to work with were all chs at the time. Of course some these file systems have evolved so they can work without chs.

The bigger breakers are items like bind mounts and namespaces.

So you are right that CHS is not the relevant cause of why we need mount api now. But CHS file systems is a correlation with with the true problem that the early mount syscall was not really designed for the environment we have today and that goes back to early Linux only being thought of as a minor toy operating system so mount syscall did not get long term design planing just enough to get the job done with a small amount of expand options that we have well and truly out grown.