[prev in list] [next in list] [prev in thread] [next in thread] 

List:       systemd-devel
Subject:    Re: [systemd-devel] rename a block device
From:       Pascal <patatetom () gmail ! com>
Date:       2022-04-25 14:50:29
Message-ID: CAGhAaddMm6wZQF8P+ERrieZ-zwx6+mL7Qkd4=avaf_JLxKZ=Uw () mail ! gmail ! com
[Download RAW message or body]

thanks for this quick feedback Lennart.
don't worry, this is not an evolution request for systemd :-)
yes for blockdev --setro and, unfortunately, yes for overflows from file
systems.
*I had once considered using qemu-nbd/snapshot to "tolerate" some writes
without altering the real device (because absorbed by the snapshot)...*

regards, lacsaP.

Le lun. 25 avr. 2022 =C3=A0 16:33, Lennart Poettering <lennart@poettering.n=
et> a
=C3=A9crit :

> On Mo, 25.04.22 16:25, Pascal (patatetom@gmail.com) wrote:
>
> > hi,
> >
> > the udev rules prohibit renaming anything other than a network device :
> > what is (would be) the way to really rename a block device (not just to
> > create a symbolic link) ?
>
> This functionality does not exist in the kernel to my knowledge. And
> the uevents for renaming network interface devices are messy enough to
> handle, let's please not add this for another subsystem!
>
> Are you aware of the udev.blockdev_read_only kernel cmdline option
> btw?
>
> (note that Linux is broken, marking a block device read-only actually
> is cosmetics mostly. File systems you mount from them may and do still
> write to the devices happily regardless whether read-only or
> not. Event through loopbck devices actually. You need to pass
> 'norecovery' as mount option to relevant file systems if you want
> true read-only access. It's crazy, if you ask me)
>
> Lennart
>
> --
> Lennart Poettering, Berlin
>

[Attachment #3 (text/html)]

<div dir="ltr"><div>thanks for this quick feedback Lennart.</div><div>don&#39;t \
worry, this is not an evolution request for systemd :-)</div><div>yes for <span \
style="font-family:monospace">blockdev --setro</span> and, unfortunately, yes for \
overflows from file systems.</div><div><i>I had once considered using <span \
style="font-family:monospace">qemu-nbd/snapshot</span> to &quot;tolerate&quot; some \
writes without altering the real device (because absorbed by the \
snapshot)...</i></div><div><br></div><div>regards, lacsaP.<br></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">Le  lun. 25 avr. 2022 Ã   \
16:33, Lennart Poettering &lt;<a \
href="mailto:lennart@poettering.net">lennart@poettering.net</a>&gt; a écrit  \
:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mo, 25.04.22 16:25, \
Pascal (<a href="mailto:patatetom@gmail.com" target="_blank">patatetom@gmail.com</a>) \
wrote:<br> <br>
&gt; hi,<br>
&gt;<br>
&gt; the udev rules prohibit renaming anything other than a network device :<br>
&gt; what is (would be) the way to really rename a block device (not just to<br>
&gt; create a symbolic link) ?<br>
<br>
This functionality does not exist in the kernel to my knowledge. And<br>
the uevents for renaming network interface devices are messy enough to<br>
handle, let&#39;s please not add this for another subsystem!<br>
<br>
Are you aware of the udev.blockdev_read_only kernel cmdline option<br>
btw?<br>
<br>
(note that Linux is broken, marking a block device read-only actually<br>
is cosmetics mostly. File systems you mount from them may and do still<br>
write to the devices happily regardless whether read-only or<br>
not. Event through loopbck devices actually. You need to pass<br>
&#39;norecovery&#39; as mount option to relevant file systems if you want<br>
true read-only access. It&#39;s crazy, if you ask me)<br>
<br>
Lennart<br>
<br>
--<br>
Lennart Poettering, Berlin<br>
</blockquote></div>



[prev in list] [next in list] [prev in thread] [next in thread]