Re: Re: Raid1 of a slow hdd and a fast(er) SSD, howto to prioritize the SSD?

[Andrea Gelmini <andrea.gelmini@gmail.com>]

Il giorno sab 9 gen 2021 alle ore 22:40 Zygo Blaxell
<ce3g8jdj@umail.furryterror.org> ha scritto:
>
> On Fri, Jan 08, 2021 at 08:29:45PM +0100, Andrea Gelmini wrote:
> > Il giorno ven 8 gen 2021 alle ore 09:36 <Cedric.dewijs@eclipso.eu> ha scritto:
> > > What happens when I poison one of the drives in the mdadm array using this command? Will all data come out OK?
> > > dd if=/dev/urandom of=/dev/dev/sdb1 bs=1M count = 100?
> You have used --assume-clean and didn't tell mdadm otherwise since,
> so this test didn't provide any information.

I know mdadm, no need of your explanation.

"--assume-clean" is used on purpose because:
a) the two devices are already identical;
b) no need two sync something (even if they were random filled), that
are going to be formatted and data filled, so - more or less - each
block is rewritten.

> On real disks a mdadm integrity check at this point fail very hard since
> the devices have never been synced (unless they are both blank devices
> filled with the same formatting test pattern or zeros).

I disagree. My point is: who cares about blocks never touched by the filesystem?

> > root@glet:/mnt/sg10# dd if=/dev/urandom of=/dev/loop32 bs=1M count=100
>
> With --write-mostly, the above deterministically works, and
>
>         dd if=/dev/urandom of=/dev/loop31 bs=1M count=100
>
> deterministically damages or destroys the filesystem.

My friend, read the question, he asked about what happens if you
poison the second device.
Of course if you poison /dev/md0 or the main device what else can
happen, in such situation?
Thanks god you told us, because we are all so much stupid!

My point of view is: you can use mdadm to defend from real case
scenario  (first hard drive die,
the second slow one goes on, and you have all your data up to date,
and if you are afraid of
bit rotten data, you have btrfs checksum).
Also, even if the second/slow hard drive is out-of-sync of seconds, it
would like if unplugged while working.
All cool feature of BTRFS (transaction, checksums, dup btree and so
on) will recover filesystem and do the rest, isn't it?

Thinking about "what if I trick my system here and there" is
absolutely fun, but no real use case, for me.

What if I expose BTRFS devices to cosmic rays and everything is wiped out?

(I know, my only hero Qu is already preparing a patch - as usual -
while others starts to write poems...)

Don't take it personally and smile,
Gelma