Bug 2024261
| Summary: | MegaRAID is slow to load the initramfs | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Renaud Métrich <rmetrich> | ||||||
| Component: | parted | Assignee: | Brian Lane <bcl> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | Release Test Team <release-test-team-automation> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | 8.5 | CC: | bcao, bcl, kzak, lipan, rharwood, weihao.bj, zhouling12 | ||||||
| Target Milestone: | rc | Flags: | pm-rhel:
mirror+
|
||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2021-12-08 22:53:13 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Renaud Métrich
2021-11-17 17:19:35 UTC
I am not sure that CHS has anything to do with your slowdown. parted cannot change the disk geometry, that ultimately comes from the BIOS. parted does write it to the msdos partition table for each partition, and yes this changed back in 2016 to fix a problem with the values returned by HDIO_GETGEO being incorrect. But that really shouldn't have any effect. The reason you are seeing different values for CHS from sfdisk is because the kernel uses one detection method when the disk is empty, and another when it has partitions -- it looks for the largest partition. But in the end these numbers really have no meaning for modern storage, so I wouldn't depend on them for anything. j I also cannot find any code in grub2 that a different CHS setting would have an effect on, grub2 gets the disk geometry from the BIOS via an int13 call not from the partition table. It might be possible that the MegaRAID itself is sensitive to the CHS values, but really it shouldn't be using them for anything, and that's outside the scope of things we can fix. If you can find some way to compare booting with only changes to the partition table, nothing else, that might lead to what's actually going on. I'm attaching 2 screenshots of a test made with various geometry: - the one as created by RHEL7 parted: 255/1023/63 - the one as created by RHEL8 parted: 255/480/2 This are the traces I added inside Grub, when performing a loading of a 10MB file. Clearly the issue is with the number of sectors per track, which forces Grub to only read by chunk of 2 sectors, instead of up to 63, resulting in tons of I/Os which seem to be slow with MegaRAID. Created attachment 1845284 [details]
Test with "RHEL7" partitioning (S=63)
Created attachment 1845285 [details]
Test with "RHEL8" partitioning (S=2)
Looking at the grub2 code I think it's pretty clear this is a MegaRAID bug. I can only assume what they are doing, but it looks like they grab the CHS from the start of the first partition and use that, passing it back to grub2 via the INT13 call in grub_biosdisk_get_diskinfo_standard. I don't think there is anything parted can do here. The smaller CHS value in parted 3.2 is a result of a bugfix that has been present for years that fixed boot failures with SD cards, so I am not willing to change it and take the risk of re-breaking those systems. I think you'll have to try to file a bug with MegaRAID. Development Management has reviewed and declined this request. You may appeal this decision by reopening this request. *** Bug 2102075 has been marked as a duplicate of this bug. *** |