What is the usecase for this?  When (or why) would we want to rename a mounted filesystem's device, then grow it?

User's workflow - 

Create an LV.
Mount it and use it.
Now - for whatever reason 'rename' of LV is needed (i.e. to reuse the name for something else).

And now you need to resize such mounted LV.


I'm not saying this is some major use-case - but it's quite limiting to think about resizing & renaming which is not working ok.

Clearly there is also known 'workaround' which does require either umount, or postponing rename to next mount time - but the limit is a 

A side note - resize_reiserfs is the ONLY tool I know so far which seems to handle this particular case nicely.

As I said in the xfs bug, I think that if you want this to work you need a kenrel interface to change what is in /proc/mounts (and, possibly an interface to change /etc/mtab)

getmntent(3) is /the/ way to iterate mounted filesystems and gather status.  If you rip a devicename out from under it, there should be no real surprise that getmntent() iterators no longer find the filesystem...

Or a simpler solution would be to disallow renames of mounted devices...

The more I think about this ... we're not going to try to work around this.  getmntent() is a widely used system interface to identify mounted devices, and it relies on what is in /proc/mounts and/or /etc/mtab.  If you rip devicenames out from under it, things fail, and I don't think you can expect every getmntent() user to work around that.

Please think about this issue a bit longer.

As already mentioned -  resize_reiserfs DOES handle this case nicely - so it proves the point it CAN easily work.

So surely it's not true you need to change anything in kernel or any API in getmntent.

I've already updated  'fsadm' script to disallow  resize with broken  resize2fs & xfs_growfs - and I'm able to perfectly recognize mounted device on any mountpoint in plain bash script with just  'stat' command - so all needed info is easily accessible.

Effectively tools like 'resize2fs'  do resize a device - it does not need to be mounted to be resized - so what does matter here is  MAJOR:MINOR -  anything like device path is really irrelevant - and even changes over the time of kernel evolution - i.e. dm device name were shown with numbers of ways in past already.

So if you think about this more - tools should be improved to handle the only stable and unique interface  kernel provides -  MAJOR:MINOR - using path is never going to 'good enough'.

No.  You can't rip mounted device names out of the system, leaving /proc/partitions invalid and inconsistent, and expect userspace to not break all over.

If you want to be able to do that, you will need to add an interface to the kernel to keep the kernel's view of mounted devices consistent when you change mounted device names, and update /etc/mtab as well, if it's not a symlink.

We're not going to chase through every user of getmntent() that breaks and rewrite them so that they work when LVM does unfriendly things.  Just because we can hack around the damage in some cases does not mean that it is the right approach.

> Effectively tools like 'resize2fs' do resize a device - it does not need to be mounted to be resized

Sure, and if it's not mounted, it will work just fine.

My complaint is not about renaming devices, it is about renaming /mounted/ devices.

We have too much critical work on our plate to spend time chasing weird, corner-case, broken behavior like this.

Sorry, for posterity: I referenced /proc/partitions when I meant /proc/mounts.

Well just minor notice -  /proc/mounts is already replaced with far better /proc/self/mountinfo   which does provide major:minor.

So as said - renamed device can be easily identified with major:minor.

You might also be unware of problem with 'duplicate' devices - where  udev is simply replacing  device path with whatever 'random' devices is placed in.

So anything that identifies devices by /dev path is implicitly  broken by current udev design -  the only real valid identifier is simply major:minor.