Comment 135 for bug 599255

This bug is ancient, and perhaps nobody cares anymore, but I've figured out a bit more about where we are left with respect to this.

dmraid userland always assumes that the sector size is 512. It is a hard-coded constant value.

Meanwhile, in kernel land, dm devices always map their sector sizes, both logical and physical, to the logical sector size of their underlying devices.

Perhaps in order to deal with this discrepancy, there is code in dmraid userland to ignore any drive whose sector size is not 512. That code doesn't get triggered, as in this case the problem is that Promise wants to virtualize the sector size, as they do in their scsi miniport driver for windows.

Check out this:

https://www2.ati.com/relnotes/AMD_RAIDXpert_User_v2.1.pdf, (p. 107)

If that's right, we might be able to work around this whole mess, having our dual-boot cake and eating it, too, by creating multiple volumes of size less than 2TB, keeping MBR on them (as linux does not grok GPT-partitioned dynamic disks) and using LDM to piece them together.

For my part, looking at the state the dmraid code and Promise metadata are in, I'm disinclined to rely on it at all; I'm just going to give up on fully functional dual-boot, use md-raid, and an emulated NAS if I need access to my other-system data from Windows.

That stated, I guess, to solve the problem fundamentally, in linux, we'd either need to extend dmraid to support emulated, metadata-based sector sizes, both in the kernel and the userland code-bases, or to implement some hack to change the logical geometry of the physical devices before setting up these arrays (but see https://bugzilla.redhat.com/show_bug.cgi?id=624335 which suggests this might not work, anyhow).

It's hard to see anyone putting that kind of effort into the increasingly marginalized dm-raid framework so I wouldn't hold my breath...