mdadm fails to recognise DDF partitions from Marvell MV64460 controller

mdadm fails to recognise DDF partitions from Marvell MV64460 controller

[Patrick Smears]

Hi,

I have a Lenovo D20 server, which has a Marvel MV64460 (fake)RAID 
controller.

For various reasons I need to be able to dual-boot the machine with 
Windows, so I need to use the native RAID format (which the Windows 
drivers understand).

It uses DDF metadata on its partitions, which I've been using 
successfully with "dmraid" for some time, but I'd like to move to mdadm 
since the dmraid support is lacking in a number of respects (e.g. cannot 
create metadata; cannot rebuild arrays, etc...).

Unfortunately, though dmraid recognises the partition as DDF, mdadm does 
not - it always reports the disk as having no superblock.

I've done some debugging on this, and it appears that the RAID 
controller's BIOS departs from the DDF spec in a couple of (minor) ways 
- and so because mdadm is stricter in its checks than dmraid, it refuses 
to recognise the disk.

I think I can come up with a patch to work around this - should I do 
that and submit it (and if so, where should I send it)? Or would it be 
better to describe the issues I've found in more detail first?

Regards,

Patrick

Re: mdadm fails to recognise DDF partitions from Marvell MV64460 controller

[NeilBrown]

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

On Fri, 06 Dec 2013 17:44:28 +0000 Patrick Smears <patrick@smears.org> wrote:

> Hi,
> 
> I have a Lenovo D20 server, which has a Marvel MV64460 (fake)RAID 
> controller.
> 
> For various reasons I need to be able to dual-boot the machine with 
> Windows, so I need to use the native RAID format (which the Windows 
> drivers understand).
> 
> It uses DDF metadata on its partitions, which I've been using 
> successfully with "dmraid" for some time, but I'd like to move to mdadm 
> since the dmraid support is lacking in a number of respects (e.g. cannot 
> create metadata; cannot rebuild arrays, etc...).
> 
> Unfortunately, though dmraid recognises the partition as DDF, mdadm does 
> not - it always reports the disk as having no superblock.
> 
> I've done some debugging on this, and it appears that the RAID 
> controller's BIOS departs from the DDF spec in a couple of (minor) ways 
> - and so because mdadm is stricter in its checks than dmraid, it refuses 
> to recognise the disk.
> 
> I think I can come up with a patch to work around this - should I do 
> that and submit it (and if so, where should I send it)? Or would it be 
> better to describe the issues I've found in more detail first?
> 

A patch is often a good way to describe an issue in detail - though you
should include plain-language text as well of course.
Patches can be posted to this list.

The only "DDF" I've come across which mdadm doesn't like is DDFv1.0 which has
all multi-byte values in the "other" order, and uses a different checksum
algorithm.  As I cannot find  a document describing DDFv1.0 I cannot
calculate the checksum so I cannot update the metadata, so I cannot use
DDFv1.0.

If the "minor" variances you found don't prevent us from being able to update
the metadata and still have it recognised by the card, then I'm certainly
interested in a patch.

Thanks,
NeilBrown

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

Re: mdadm fails to recognise DDF partitions from Marvell MV64460 controller

[Patrick Smears]

On Sat, 7 Dec 2013, NeilBrown wrote:

>> I think I can come up with a patch to work around this - should I do
>> that and submit it (and if so, where should I send it)? Or would it be
>> better to describe the issues I've found in more detail first?
>
> A patch is often a good way to describe an issue in detail - though you 
> should include plain-language text as well of course. Patches can be 
> posted to this list.

Great, thanks - I'll see what I can come up with.

> The only "DDF" I've come across which mdadm doesn't like is DDFv1.0 
> which has all multi-byte values in the "other" order, and uses a 
> different checksum algorithm.  As I cannot find a document describing 
> DDFv1.0 I cannot calculate the checksum so I cannot update the metadata, 
> so I cannot use DDFv1.0.

The metadata claims to be DDFv1.2, but the implementation appears to be 
buggy. One of the bugs is that the CRC is non-standard, but I've managed 
to figure out how it calculates it, so it should be possible to update the 
metadata OK. I'll include full details with the patch.

-P

> If the "minor" variances you found don't prevent us from being able to 
> update the metadata and still have it recognised by the card, then I'm 
> certainly interested in a patch.
>
> Thanks,
> NeilBrown
>

-- 
* Ensoft Limited, Registered in Cardiff No. 3351902
* Registered Office: 13 Station Road, Finchley, London N3 2SB