[linux-lvm] LVM and RO device/partition(s

Zdenek Kabelac zdenek.kabelac at gmail.com
Wed Mar 22 14:11:09 UTC 2023

Dne 20. 03. 23 v 17:37 lacsaP Patatetom napsal(a):
> hi,
> I come back to you with the memo mentioned : 
> https://github.com/patatetom/lvm-on-readonly-block-device 
> <https://github.com/patatetom/lvm-on-readonly-block-device>
> I hope that it will allow you to better understand this problem of alteration 
> of the disk.
> as I mentioned, LVM should normally/theoretically not touch the disk as long 
> as it is read-only, but what bothers me the most is the fact that I can't 
> "catch up" by correcting the new 6.1.15 kernel as I did before.
> regards, lacsaP.
> Le lun. 20 mars 2023 à 15:15, lacsaP Patatetom <patatetom at gmail.com 


So I'm possibly finally starting to understand your problem here.

You are using your own patched kernel - where you were reverting
a32e236eb93e62a0f692e79b7c3c9636689559b9  linux kernel patch.

without likely understanding the consequences.

With kernel 6.X there is commit bdb7d420c6f6d2618d4c907cd7742c3195c425e2
modifying bio_check_ro() to return void  - so your 'reverting' patch
is no longer usable the way it's been created.

 From your github report it seems you are creating  'raid' across 3 sdb drives.

So with normal kernel - it happens to be that  'dm' drives are allowed to 
bypass any 'read-only' protection set on a device.

So when you actually creating raid LV on  loop0 & loop1 - deactivate, then you 
make loop0 & loop1  read-only, active raid LV - then you can easily call 
'mkfs' and it will normally work.

Raid device consist or  '_rimage' & '_rmeta' LV per leg - where _rmeta is 
metadata device updated with activation of raid LV.

So when your local 'revert' patch for 6.X kernel no longer works - there is no 
surprise that your  'sdbX' drives are being actually modified - since ATM  dm 
targets are allowed to bypass  read-only protection.

Since the reason for the  'bypass' (snapshot read-only activation)  was fixed 
5 years ago we should probably build some better way how to restore to 
'read-only' protection - and allow to disable it only when user requests such 
behavior due to use of old user-space tooling.



More information about the linux-lvm mailing list