| Summary: | dmraid cannot use isw RAID0 array | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Loïc Yhuel <loic.yhuel> | ||||||||||
| Component: | kernel | Assignee: | Heinz Mauelshagen <heinzm> | ||||||||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
| Severity: | high | Docs Contact: | |||||||||||
| Priority: | unspecified | ||||||||||||
| Version: | 15 | CC: | agk, bmr, dwysocha, gansalmon, hdegoede, heinzm, itamar, jonathan, kernel-maint, lvm-team, madhu.chinakonda, prockai, zkabelac | ||||||||||
| Target Milestone: | --- | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | x86_64 | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2012-07-11 17:50:03 UTC | Type: | --- | ||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Attachments: |
|
||||||||||||
Created attachment 494349 [details]
"dmraid -rD" output
Created attachment 494351 [details]
metadata dump (created by "dmraid -rD")
Similar to bug 679099 I created : it's caused by HPA. On Fedora 13, the RAID0 array is working properly, dmraid finds isw_iceabchhc on sda too (perhaps some old metadata in the HPA zone, or the disk size being different is enough to change the identifier ?) On F13: /dev/sda: max sectors = 1250261615/1250263728, HPA is enabled /dev/sdb: max sectors = 1250263728/1250263728, HPA is disabled /dev/sdc: max sectors = 976771055/976773168, HPA is enabled /dev/sdd: max sectors = 125037167/125045424, HPA is enabled On F14/F15: /dev/sda: max sectors = 1250263728/1250263728, HPA is disabled /dev/sdb: max sectors = 1250263728/1250263728, HPA is disabled /dev/sdc: max sectors = 976771055/976773168, HPA is enabled /dev/sdd: max sectors = 125045424/125045424, HPA is disabled (In reply to comment #3) > Similar to bug 679099 I created : it's caused by HPA. Sorry, bug 699079 [ 1.600138] sda: p3 size 2090905600 extends beyond EOD, enabling native capacity [ 1.600155] ata1: hard resetting link [ 2.059401] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.061115] ata1.00: n_sectors mismatch 1250261615 != 1250263728 [ 2.061118] ata1.00: new n_sectors matches native, probably late HPA unlock, n_sectors updated The partition is bigger than the disk, which is expected for RAID0. But it causes the kernel to unlock HPA, and then dmraid looks at the end of the disk and finds the wrong metadata. On reboot, the HPA is probably still unlocked, so the RAID BIOS does the same. So it would mean the HPA is set by the BIOS (not RAID BIOS) on cold boot, but for some unknown reason it does not apply to /dev/sdb. On F13, the kernel does not unlock the HPA, so dmraid looks at the end of the HPA and finds the correct metadata. (In reply to comment #5) > On reboot, the HPA is probably still unlocked, so the RAID BIOS does the same. > So it would mean the HPA is set by the BIOS (not RAID BIOS) on cold boot, but > for some unknown reason it does not apply to /dev/sdb. Another possibility : the RAID BIOS may have set a permanent HPA when creating the RAID array, so it does not send the command on boot. Created attachment 494769 [details]
kernel patch
I patched my kernel to fix my problem.
Here is the idea :
Previously, any partition starting/ending after current EOD would unlock HPA, even if it would still be incomplete.
Now, HPA is only unlocked if there is a partition which ends in the area between current EOD and native capacity, ie it does not unlock if it would only make an incomplete partition bigger but still incomplete.
It will cover nearly all RAID cases. I don't see how to cover absolutely all cases without having dmraid in kernel to check metadata before unlocking HPA.
About the patch :
- I don't know if it's done the proper way
- It's not complete : only libata is implemented
Did you send your patch upstream? If not, could you? Or is this fixed in later kernel updates? Fedora 15 has reached it's end of life as of June 26, 2012. As a result, we will not be fixing any remaining bugs found in Fedora 15. In the event that you have upgraded to a newer release and the bug you reported is still present, please reopen the bug and set the version field to the newest release you have encountered the issue with. Before doing so, please ensure you are testing the latest kernel update in that release and attach any new and relevant information you may have gathered. Thank you for taking the time to file a report. We hope newer versions of Fedora suit your needs. |
Created attachment 494348 [details] "dmraid -n" output Description of problem: dmraid sees two RAID arrays with only one disk each. The array is working on Windows. I'm not sure if it's linked or if it's another bug (kernel perhaps ?), but after booting Fedora, I must shutdown my computer. If I reboot the RAID BIOS will see the disks as "Offline member" an Windows will not be able to use them until a shutdown. "dmraid -ay" : ERROR: isw: wrong number of devices in RAID set "isw_dhjhdjbcbh_WD640" [1/2] on /dev/sda ERROR: isw: wrong number of devices in RAID set "isw_iceabchhc_WD640" [1/2] on /dev/sdb RAID set "isw_dhjhdjbcbh_WD640" was not activated ERROR: device "isw_dhjhdjbcbh_WD640" could not be found RAID set "isw_iceabchhc_WD640" was not activated ERROR: device "isw_iceabchhc_WD640" could not be found Version-Release number of selected component (if applicable): dmraid-1.0.0.rc16-15.fc15.x86_64 "dmraid --version" : dmraid version: 1.0.0.rc16 (2009.09.16) debug dmraid library version: 1.0.0.rc16 (2009.09.16) device-mapper version: 4.19.1 Additional info: See attached output of : dmraid -n dmraid -rD (and tar of the dumped metadata)