Re: mkfs.xfs states log stripe unit is too large
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 errormessage. SID is leading (better?) edge, and is obviously using a recentmdadm release, which defaults to metadata 1.2, and chunk of 512KB. As more distros adopt newer mdadm, reports of this will be moreprevalent. So Eric's idea is likely preferable than mine. XFS making arecommendation 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". =:-OSandbagging 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