Interesting mdadm quirk ...

Interesting mdadm quirk ...

[Wols Lists]

Just been doing some raid testing, and this happened ...

linux-lfqf:/dev # mdadm md/parity
md/parity: 31.97GiB raid5 3 devices, 0 spares. Use mdadm --detail for
more detail.
linux-lfqf:/dev # mdadm --stop md/parity
mdadm: Cannot open md/parity
linux-lfqf:/dev # mdadm --stop /dev/md/parity
mdadm: stopped /dev/md/parity

Weird - why can it successfully stop it when passed an absolute path,
but not when passed a relative path? When I did the first variant, I
used tab completion, and then when I edited it I really did edit it, not
retype it, so I can't see any way the two arguments could refer to
different objects.

Oh - and

mdadm --version
mdadm - v3.4 - 28th January 2016

ie stock SuSE leap 42.2

Cheers,
Wol

Re: Interesting mdadm quirk ...

[NeilBrown]

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

On Sun, Jan 08 2017, Wols Lists wrote:

> Just been doing some raid testing, and this happened ...
>
> linux-lfqf:/dev # mdadm md/parity
> md/parity: 31.97GiB raid5 3 devices, 0 spares. Use mdadm --detail for
> more detail.
> linux-lfqf:/dev # mdadm --stop md/parity
> mdadm: Cannot open md/parity
> linux-lfqf:/dev # mdadm --stop /dev/md/parity
> mdadm: stopped /dev/md/parity
>
> Weird - why can it successfully stop it when passed an absolute path,
> but not when passed a relative path? When I did the first variant, I
> used tab completion, and then when I edited it I really did edit it, not
> retype it, so I can't see any way the two arguments could refer to
> different objects.

If you give mdadm a name of an array that start with "/", it is assumed
to be a path name (usually in /dev).
If it doesn't start with "/", then it is an array name.  The might mean
different things in different contexts, I'm not 100% sure.
However, for --stop, it a name like you would find is /sys/block or
/proc/mdstat.
So "mdadm --stop md0" or "mdadm --stop md_parity" might do what you
want.
Probably the error message could be more useful here.

NeilBrown


>
> Oh - and
>
> mdadm --version
> mdadm - v3.4 - 28th January 2016
>
> ie stock SuSE leap 42.2
>
> Cheers,
> Wol
> --
> 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

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

Re: Interesting mdadm quirk ...

[Wols Lists]

On 08/01/17 22:44, NeilBrown wrote:
> On Sun, Jan 08 2017, Wols Lists wrote:
> 
>> Just been doing some raid testing, and this happened ...
>>
>> linux-lfqf:/dev # mdadm md/parity
>> md/parity: 31.97GiB raid5 3 devices, 0 spares. Use mdadm --detail for
>> more detail.
>> linux-lfqf:/dev # mdadm --stop md/parity
>> mdadm: Cannot open md/parity
>> linux-lfqf:/dev # mdadm --stop /dev/md/parity
>> mdadm: stopped /dev/md/parity
>>
>> Weird - why can it successfully stop it when passed an absolute path,
>> but not when passed a relative path? When I did the first variant, I
>> used tab completion, and then when I edited it I really did edit it, not
>> retype it, so I can't see any way the two arguments could refer to
>> different objects.
> 
> If you give mdadm a name of an array that start with "/", it is assumed
> to be a path name (usually in /dev).
> If it doesn't start with "/", then it is an array name.  The might mean
> different things in different contexts, I'm not 100% sure.
> However, for --stop, it a name like you would find is /sys/block or
> /proc/mdstat.
> So "mdadm --stop md0" or "mdadm --stop md_parity" might do what you
> want.
> Probably the error message could be more useful here.
> 
Does that mean an array name can contain a "/"?

Assuming it can't, surely it's better to alter the logic slightly...

if char[0] ne '/' then
  open array_name
end
if not successful then
  open path_name
  if error then go error_handler
end
carry on ...

That way naive users like me won't get a surprise. And it is rather
inconsistent for it to work with one sort of path but not another ...
and actually that logic will work fine even if the name does contain a
"/" :-)

Cheers,
Wol

Re: Interesting mdadm quirk ...

[NeilBrown]

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

On Mon, Jan 09 2017, Wols Lists wrote:

> On 08/01/17 22:44, NeilBrown wrote:
>> On Sun, Jan 08 2017, Wols Lists wrote:
>> 
>>> Just been doing some raid testing, and this happened ...
>>>
>>> linux-lfqf:/dev # mdadm md/parity
>>> md/parity: 31.97GiB raid5 3 devices, 0 spares. Use mdadm --detail for
>>> more detail.
>>> linux-lfqf:/dev # mdadm --stop md/parity
>>> mdadm: Cannot open md/parity
>>> linux-lfqf:/dev # mdadm --stop /dev/md/parity
>>> mdadm: stopped /dev/md/parity
>>>
>>> Weird - why can it successfully stop it when passed an absolute path,
>>> but not when passed a relative path? When I did the first variant, I
>>> used tab completion, and then when I edited it I really did edit it, not
>>> retype it, so I can't see any way the two arguments could refer to
>>> different objects.
>> 
>> If you give mdadm a name of an array that start with "/", it is assumed
>> to be a path name (usually in /dev).
>> If it doesn't start with "/", then it is an array name.  The might mean
>> different things in different contexts, I'm not 100% sure.
>> However, for --stop, it a name like you would find is /sys/block or
>> /proc/mdstat.
>> So "mdadm --stop md0" or "mdadm --stop md_parity" might do what you
>> want.
>> Probably the error message could be more useful here.
>> 
> Does that mean an array name can contain a "/"?

No, it cannot.

>
> Assuming it can't, surely it's better to alter the logic slightly...
>
> if char[0] ne '/' then
>   open array_name
> end
> if not successful then
>   open path_name
>   if error then go error_handler
> end
> carry on ...
>
> That way naive users like me won't get a surprise. And it is rather
> inconsistent for it to work with one sort of path but not another ...
> and actually that logic will work fine even if the name does contain a
> "/" :-)

If you can convert the above into a patch.....

I agree with your logic.

NeilBrown

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