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

[NeilBrown <neilb@suse.de>]

[-- 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 --]