On 07/14/2020 08:26 AM, Lew Wolfgang wrote:
On 07/14/2020 02:10 AM, Dave Howorth wrote:
On Mon, 13 Jul 2020 23:57:45 -0700 Lew Wolfgang <wolfgang@sweet-haven.com> wrote:
On 07/13/2020 11:32 PM, Per Jessen wrote:
Lew Wolfgang wrote:
Today I booted the 15.1 rescue system and determined that mount works! It reported:
4096 byte physical blocks 574218043392 blocks for sda1 (drive lettering changed) 273437163520 blocks for sdb1
Back running 15.2, fdisk reports the same block counts as 15.1.
Note that 15.1 was able to mount the XFS partitions created by 15.2's mks.xis.
This implies to me that the problem is probably in the 15.2 XIS kernel module? I would be tempted to think so too, yes. OTOH, I went and googled it -
https://bugzilla.kernel.org/show_bug.cgi?id=202127 (also large XFS filesystem on hardware RAID).
I only skimmed it quickly, but they seem to be thinking it is a config issue at time of filesystem creation. Wow, thanks Per! That sure looks like my problem. It may be a Broadcom controller firmware bug that was revealed with more recent Linux kernels. I'll look into updating the firmware, tomorrow. I just finished 16-oz of sangria with frozen blueberries, and it's 11:52-PM. One should not do root-ish things when drinking wine!
Regards, Lew It appears you may need to add your data and customer opinion weight to daimh's bug report to Broadcom.
It sounds like you can fix the new filesystems by overriding the firmware's buggy values as described in #23, #24 and if you have any existing filesystems, you'll be able to mount them as described in #30
That kind of response from Eric and Dave is why I like XFS! :)
I think I'll try updating the firmware first, if applicable. We have dozens of older boxes with petabytes of stuff that may be threatened by Leap 15.2. At least this current box is new and doesn't have any production data on it yet.
I still haven't gotten a confirmation about where/how to update the firmware in this case. It's Broadcom controller modified by SuperMicro. But in any case, in chasing down issues with methods suggested by Anthony Iliopoulos (Kernel Team) I discovered that the RAID volumes in question, when they were created with the Broadcom GUI, a parameter for stripe size was increased beyond the suggested default. This change created the I/O size clash that was flagged by the Leap 15.2 XFS kernel module. I deleted the two volumes, and re-created them without changing the defaults, and all is well! Left as a problem for the near future is that we'll probably see this again when upgrading existing 15.1 servers, but at least we'll be prepared for the unpleasantness and be able to take appropriate action. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org