mdadm fails to recognise DDF partitions from Marvell MV64460 controller
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
Quoted 17 lines · On Fri, 06 Dec 2013 17:44:28 +0000 Patrick Smears <[email protected]> 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.
Quoted 9 lines
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
Quoted 5 lines · NeilBrown
Quoted 3 lines
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.
Quoted 1 line
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
Quoted 5 lines
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
Signature · 2 lines
* Ensoft Limited, Registered in Cardiff No. 3351902 * Registered Office: 13 Station Road, Finchley, London N3 2SB