On Mon, 17 Jan 2022, Linus Torvalds wrote: > On Mon, Jan 17, 2022 at 12:07 AM NeilBrown <neilb@xxxxxxx> wrote: > > > > Since that was changed, the mount options used for devtmpfs are ignored. > > This is a regression which affect systemd - which mounts devtmpfs > > with "-o mode=755,size=4m,nr_inodes=1m". > > Hmm, I've applied this, but I'd have loved to see what the actual > symptoms of the problem were. Particularly since it's apparently been > broken for 18 months with this being the first I hear of it. > > Yes, yes, I could (and did) search for this on the mailing lists, and > found the discussion and more information, but I think that info > should have been in the commit message rather than me having to go > look for it just to see the clarifications.. Sorry about that. The trail was a bit convoluted and I hadn't bothered to straighten it out as the behavioural change was so easy to demonstrate. I've had a better look now. A customer with a 5.3 based kernel reported that udev was having problems creating all the symlinks for lots of LUNs for some storage array (With dm devices over the LUNs etc). It ran out of inodes because systemd always mounts devtmpfs with size=4m,nr_inodes=64k This was bumped to 128k and then to 1m in systemd-v250. We provided our customer with a systemd which used a larger limit, but when we tested this fix on Tumbleweed (with a newer kernel), we noticed that it had no effect. Now admittedly the default provided by the kernel is a lot bigger than even the current 1m setting from systemd so maybe this doesn't matter. Had the commit which changed behaviour said "systemd sets nr_inodes to a stupidly low number, let's just ignore the mount options", then I probably would have accept it. But it looked like behaviour change without justification and that suggests a regression. So I patched it. Thanks, NeilBrown
