On 6/23/2012 9:20 PM, Eric Sandeen wrote:
> On 6/23/12 6:44 PM, Dave Chinner wrote:
>> On Sat, Jun 23, 2012 at 02:50:49PM +0200, Ingo Jürgensmann wrote:
>>> muaddib:~# cat /proc/mdstat
>>> Personalities : [raid1] [raid6] [raid5] [raid4]
>>> md7 : active raid5 sdf4 sdd4 sde4
>>> 7811261440 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3]
The the log stripe unit mismatch error is a direct result of Ingo
manually choosing a rather large chunk size for his two stripe spindle
md array, yielding a 1MB stripe, and using an internal log with it.
Maybe there is a good reason for this, but I'm going to challenge it.
The default md chunk size IIRC is 64KB, 8x smaller than Ingo's chunk.
With the default it would require 16 stripe spindles to reach a 1MB
stripe. Ingo has TWO stripe spindles.
In the default case with a 1MB stripe and 16 spindles, each aligned
aggregated stripe write out will be 256 XFS blocks, or 16 blocks to each
spindle, 128 sectors (512 byte). In Ingo's case, it will be 128 XFS
blocks, 1024 sectors.
Does backup PC perform better writing 2048 sectors per stripe write,
1024 per spindle, with two spindles, than 256 sectors per stripe write,
128 per spindle, using two spindles?
>>> The RAID devices /dev/md0 to /dev/md4 are on my old 3x 1 TB
>>> Seagate disks. Anyway, to finally come to the problem, when I try
>>> to create a filesystem on the new RAID5 I get the following:
>>> muaddib:~# mkfs.xfs /dev/lv/usr
>>> log stripe unit (524288 bytes) is too large (maximum is 256KiB)
>>> log stripe unit adjusted to 32KiB
>>> So, the question is:
>>> - is this a bug somewhere in XFS, LVM or Linux's software RAID
>> Not a bug at all.
> Dave, I'd suggest that we should remove the warning though, if XFS picks
> the wrong defaults and then overrides itself.
> Rule of Silence: When a program has nothing surprising to say, it should say
I think this goes to the heart of the matter. Ingo chose an arbitrarily
large chunk size apparently without understanding the ramifications.
mkfs.xfs was written to read md parameters I believe with the assumption
the parameters were md defaults. It obviously wasn't written to
gracefully deal with a manually configured arbitrarily large md chunks size.
Maybe a better solution than silence here would be education. Flag the
mismatch as we do now, and provide a URL to a new FAQ entry that
explains why this occurs, and possible solutions to the problem, the
first recommendation being to choose a sane chunk size.
Question: does this occur with hardware RAID when entering all the same
parameters manually on the command line? Or is this error limited to
the md interrogation path?