On 2012-06-25 00:15, Stan Hoeppner wrote:
As I already wrote, I'm using Debian unstable, therefore distro
supplied mdadm. Otherwise I'd have said this.
SID is the problem here, or I should say, the cause of the error
message. SID is leading (better?) edge, and is obviously using a
recent
mdadm release, which defaults to metadata 1.2, and chunk of 512KB.
As more distros adopt newer mdadm, reports of this will be more
prevalent. So Eric's idea is likely preferable than mine. XFS
making a
recommendation against an md default would fly like a lead balloon...
Actually, even man page of Debian stable (Squeeze) mentions:
-c, --chunk=
Specify chunk size of kibibytes. The default when
creating an array is 512KB. To ensure
compatibility with earlier versions, the default when
Building and array with no persis‐
tent metadata is 64KB. This is only meaningful for
RAID0, RAID4, RAID5, RAID6, and
RAID10.
So, the question is: why did mdadm choose 1.2 format superblock this
time? My guess is, that's because of GPT labelled disks instead of MBR,
but it's only a guess. Maybe it's because the new md device is bigger in
size. All of my other md devices on MBR labelled disks do have 0.90
format superblock, all md devices on the GPT disks are of 1.2 format.
Although it doesn't seem a new default in mdadm for me, your assumption
would still stand if the cause would turn out to be the GPT label. More
and more people will start using GPT labelled disks.
I find it strange that you've misinterpreted citing the mdadm man
page as "sandbagging us". =:-O
Sandbagging simply means holding something back, withholding
information.
Are ok, I misread "sandboxing us" as "boxing onto us like at a
sandbox". So, my apologies here. :-)
--
Ciao... // Fon: 0381-2744150
. Ingo \X/ http://blog.windfluechter.net
gpg pubkey: http://www.juergensmann.de/ij_public_key.
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
