mdadm --misc --readonly -> ENODEV indefinitely

mdadm --misc --readonly -> ENODEV indefinitely

[Nix]

So I was trying to flip on the RAID journal now I'd fully populated my
array and cut over to it. So, from early userspace, I did

   # first line done by initramfs scripting
   /sbin/mdadm --assemble --scan --auto=md --freeze-reshape
   mdadm --misc --readonly /dev/md/fast
   mdadm --manage /dev/md/fast --add-journal /dev/ssd1
   mdadm --misc --readwrite /dev/md/fast

This did not work as planned, or indeed at all. After the first
--readonly, all requests for /dev/md/fast report "No such device or
address" until a reboot, though /proc/mdstat says the thing is still
there and /sys/block/md125/dev reports no change in major/minor numbers.
(I don't have udev in my early-userspace environment, but mdev reports
no change, either.)

It's a bit hard to do anything else after that, like, say, turn the
journal on.

... maybe an mdadm --assemble --scan --auto=md --readonly in one go
would work better, rather than starting with the default (?read-mostly?)
and flipping it? I'll give that a try later.

Re: mdadm --misc --readonly -> ENODEV indefinitely

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 1433 bytes --]

On Sun, May 28 2017, Nix wrote:

> So I was trying to flip on the RAID journal now I'd fully populated my
> array and cut over to it. So, from early userspace, I did
>
>    # first line done by initramfs scripting
>    /sbin/mdadm --assemble --scan --auto=md --freeze-reshape
>    mdadm --misc --readonly /dev/md/fast
>    mdadm --manage /dev/md/fast --add-journal /dev/ssd1
>    mdadm --misc --readwrite /dev/md/fast
>
> This did not work as planned, or indeed at all. After the first
> --readonly, all requests for /dev/md/fast report "No such device or
> address" until a reboot, though /proc/mdstat says the thing is still
> there and /sys/block/md125/dev reports no change in major/minor numbers.
> (I don't have udev in my early-userspace environment, but mdev reports
> no change, either.)
>
> It's a bit hard to do anything else after that, like, say, turn the
> journal on.
>
> ... maybe an mdadm --assemble --scan --auto=md --readonly in one go
> would work better, rather than starting with the default (?read-mostly?)
> and flipping it? I'll give that a try later.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Commit: 065e519e71b2 ("md: MD_CLOSING needs to be cleared after called md_set_readonly or do_md_stop")

Broken in v4.9-rc1
Fixed in v4.12-rc1

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: mdadm --misc --readonly -> ENODEV indefinitely

[Nix]

On 28 May 2017, NeilBrown told this:

> On Sun, May 28 2017, Nix wrote:
>
>> So I was trying to flip on the RAID journal now I'd fully populated my
>> array and cut over to it. So, from early userspace, I did
>>
>>    # first line done by initramfs scripting
>>    /sbin/mdadm --assemble --scan --auto=md --freeze-reshape
>>    mdadm --misc --readonly /dev/md/fast
>>    mdadm --manage /dev/md/fast --add-journal /dev/ssd1
>>    mdadm --misc --readwrite /dev/md/fast
>>
>> This did not work as planned, or indeed at all. After the first
>> --readonly, all requests for /dev/md/fast report "No such device or
>> address" until a reboot, though /proc/mdstat says the thing is still
>> there and /sys/block/md125/dev reports no change in major/minor numbers.
>> (I don't have udev in my early-userspace environment, but mdev reports
>> no change, either.)
[...]
> Commit: 065e519e71b2 ("md: MD_CLOSING needs to be cleared after called md_set_readonly or do_md_stop")
>
> Broken in v4.9-rc1
> Fixed in v4.12-rc1

Oh, apologies -- I should have checked master. :/ didn't think of it.
(And the fix hasn't hit stable in the two months since. I sort of
assumed promotion to stable was usually faster than that... but I guess
it depends on how much free time gregkh has.)

... my arrays are all humming along now, RAID-6ed and much faster than
they ever were with hardware RAID. I'm back in md land for good, where
bugs can actually get *fixed* without booting off a DOS floppy and doing
a reflash of horrible non-free firmware that if it goes wrong will make
my machine unusable.

The sense of freedom is undeniable :) thank you, mders one and all!

-- 
NULL && (void)