On 2012-06-25 22:49, Stan Hoeppner wrote:
I've never understand exactly what this means, but it's apparently
involved with some of the arrays you've built with Stable and SID:
"To ensure compatibility with earlier versions, the default when
Building and array with no persistent metadata is 64KB."
How does one "build an array with no persistent metadata"? Does this
simply mean forcing metadata .90 on the command line?
IIRC, the metadata in 1.2 is populated over the RAID whereas in 0.90 it
was only at the beginning. But take that with care. I've no source for
that assumption. It's only somewhere in my mind that I think I might
have read about this somewhere, somewhen...
Someone else will know better and correct me for sure. :-)
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.
Ok this is really interesting as this is undocumented behavior, if
indeed this is occurring. Would you mind firing up a thread about
this
on the linux-raid list?
I've talked to some guys on #debian.de in the meantime. I don't think
now that this has anything to do with GPT labels. According to
#debian.de the default behaviour in mdadm was changed after release of
Squeeze. Already before Squeeze, metadata format 0.90 was obsolete and
was only kept for Squeeze for backward compatibility reasons.
So, it's indeed a changed default within Debian, but nothing new for
upstream mdadm and it's likely that other distros have adopted the
upstream default way before Debian did.
--
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
