linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Zdenek Kabelac <zdenek.kabelac@gmail.com>
To: LVM general discussion and development <linux-lvm@redhat.com>,
	lacsaP Patatetom <patatetom@gmail.com>
Subject: Re: [linux-lvm] LVM and RO device/partition(s
Date: Wed, 22 Mar 2023 15:11:09 +0100	[thread overview]
Message-ID: <699c4cd0-fa9d-09d3-ed4f-e7139ccc1db4@gmail.com> (raw)
In-Reply-To: <CAGhAaddCmjQeOrdqueHHpM6znVpvMK_vy8XfTxgsMgWPLwyndQ@mail.gmail.com>

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@gmail.com 

Hi

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.

Regards

Zdenek

_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

  reply	other threads:[~2023-03-22 14:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-19 10:27 [linux-lvm] LVM and RO device/partition(s) Pascal
2023-03-20 13:57 ` Zdenek Kabelac
2023-03-20 14:15   ` lacsaP Patatetom
2023-03-20 16:37     ` lacsaP Patatetom
2023-03-22 14:11       ` Zdenek Kabelac [this message]
2023-03-22 14:50         ` [linux-lvm] LVM and RO device/partition(s lacsaP Patatetom

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=699c4cd0-fa9d-09d3-ed4f-e7139ccc1db4@gmail.com \
    --to=zdenek.kabelac@gmail.com \
    --cc=linux-lvm@redhat.com \
    --cc=patatetom@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).