Re: [PATCH - resend] devtmpfs regression fix: reconfigure on each mount

["NeilBrown" <neilb@suse.de>]

On Mon, 17 Jan 2022, Linus Torvalds wrote:
> On Mon, Jan 17, 2022 at 12:07 AM NeilBrown <neilb@suse.de> 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