https://bugzilla.kernel.org/show_bug.cgi?id=217965 --- Comment #51 from carlos@xxxxxxxxxxxxxx --- bugzilla-daemon@xxxxxxxxxx (bugzilla-daemon@xxxxxxxxxx) wrote on Fri, Dec 22, 2023 at 10:48:39PM -03: > https://bugzilla.kernel.org/show_bug.cgi?id=217965 > > Andreas Dilger (adilger.kernelbugzilla@xxxxxxxxx) changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |adilger.kernelbugzilla@dilg > | |er.ca > > --- Comment #48 from Andreas Dilger (adilger.kernelbugzilla@xxxxxxxxx) --- > Independent of the fixes to the mballoc code to improve the allocation > performance, I'm wondering about the ''RAID stride'' values in use here. > The "stride" value is intended to be the size of one complete set of > disks (e.g. 128KiB chunk size * 8 data disks = 1MiB). The filesystem > doesn't see the parity disks, so the number of those disks does not > matter to ext4. > > It seems in all these cases that the stripe/stride is strange. I can't > see any value to setting stride to (almost) 128MB, especially not on a > RAID-1 system. Were these values automatically generated by mke2fs, > or entered manually? If manually, why was that value chosen? If there > is something unclear in the documentation it should be fixed, and the > same if there is something wrong in mke2fs detection of the geometry. > > > By default the FS is mounted with stripe=1280 because it's on a raid6. > > Remounting with stripe=0 works around the problem. Excellent! > > Carlos, how many data disks in this system? Do you have 5x 256KiB or > 10x 128KiB *data* disks, plus 2 *parity* disks? There are 10 data disks. The stride, determined automatically by mke2fs, is correct since the chunk is 512KiB. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
