On Mon, 2020-05-25 at 11:03 -0700, Samuel Sieb wrote:
On 5/25/20 2:25 AM, Patrick O'Callaghan wrote:
> On Sun, 2020-05-24 at 16:22 -0700, Samuel Sieb wrote:
> > On 5/24/20 3:39 PM, Patrick O'Callaghan wrote:
> >
> > > So although the above message says the existing partition table will be
> > > lost, for some reason I'm still getting a partition, while you
> > > apparently didn't. I copied the --create command directly from the
man
> > > page. Is this not the "standard" way you mentioned in an earlier
reply?
> >
> > That message is a little misleading. What happened was you created an
> >
> > array out of disks with existing data on them. Only the superblock gets
> >
> > rewritten, the rest of the drive just gets resynced, not erased. So
> >
> > your existing partition table is still there.
>
> More than a little misleading. I'd call the message downright wrong.
> I'll consider reporting it to BZ.
It depends on which drive has the partition table and which drive gets
cloned to. For example, you have one blank drive and one with a
partition table. If the blank one get cloned to the other, then the
partition table gets wiped out. If it goes the other way, then your
raid has a partition table. But even in that case, depending on where
the raid metadata goes and other factors, it could mess up the table or
have it point to the wrong place. It's best to just assume that the
partition table will be invalid even if it appears to still be there.
Unless you're really sure about what you're doing, you should always
reinitialize a newly created raid array, not trusting the existing data.
That decision was taken by mdadm without input from me, i.e. it's the
default. I see there is an "--assume-clean" option which would possibly
have skipped that step, though the man page doesn't recommend it unless
you know what you're doing, which I clearly don't. All the same, saying
"the partition table *will* be lost or meaningless after creating
array" is certainly wrong.
poc