moving arrays from MBR part table install to GPT? Possible?

moving arrays from MBR part table install to GPT? Possible?

[David C. Rankin]

All,

   I suffered a controller failure on my server housing a 2-disk/4-partition 
raid1 mdraid array under Archlinux with MBR partition table. The original 
motherboard was non-UEFI, of course everything now is. I am getting conflicting 
information whether my existing arrays are usable with the new UEFI board. I 
don't know if this is the best place to ask, but heck, there is a lot of 
collective wisdom regarding mdadm here.

   I am planning to set the BIOS on the new board to Legacy and attempt to use 
my existing arrays by booting the Arch install media, assembling the arrays, 
then chrooting and rebuilding initramfs to preserve the existing setup. Is there 
any reason that can't work?. (I haven't dealt with the UEFI fun before)

   If that will not work, I'm left with installing to new drives. If I do end up 
with a full install, I'm left with the MBR or GPT partition table choice. I will 
install to 2 new drives that I want to again be setup as raid1 arrays with 
mdadmin. Does mdadmin/mdraid require a MBR partition type? Or, can I create a 
GPT partition table and use mdadm to manage the array?

   If GPT is fine, then is there anyway to migrate my existing array to a GPT 
partition table in the new box without having to install to new drives with a 
GPT table and then mount one of the existing drives to copy the data to the new 
array?

   If these questions are already answered in a link somewhere, I apologize, I 
haven't found it. Thanks for any help/advise you can provide.

-- 
David C. Rankin, J.D.,P.E.

Re: moving arrays from MBR part table install to GPT? Possible?

[Wols Lists]

On 16/08/15 07:31, David C. Rankin wrote:
> All,
> 
>   I suffered a controller failure on my server housing a
> 2-disk/4-partition raid1 mdraid array under Archlinux with MBR partition
> table. The original motherboard was non-UEFI, of course everything now
> is. I am getting conflicting information whether my existing arrays are
> usable with the new UEFI board. I don't know if this is the best place
> to ask, but heck, there is a lot of collective wisdom regarding mdadm here.

I run gentoo ... and migrated my system from mbr to gpt ...
> 
>   I am planning to set the BIOS on the new board to Legacy and attempt
> to use my existing arrays by booting the Arch install media, assembling
> the arrays, then chrooting and rebuilding initramfs to preserve the
> existing setup. Is there any reason that can't work?. (I haven't dealt
> with the UEFI fun before)

If your Arch will work on the new hardware, I suspect, actually, that
just transferring the drives across and booting will work (although I
haven't played with UEFI before either).

Your biggest problem is going to be Grub2, I expect.
> 
>   If that will not work, I'm left with installing to new drives. If I do
> end up with a full install, I'm left with the MBR or GPT partition table
> choice. I will install to 2 new drives that I want to again be setup as
> raid1 arrays with mdadmin. Does mdadmin/mdraid require a MBR partition
> type? Or, can I create a GPT partition table and use mdadm to manage the
> array?

Drives over ?2TB require GPT. It's nothing to do with the software - the
mbr (allegedly) cannot partition larger drives. gfdisk will quite
happily write both a GPT and an MBR to the disk, for the software to use
either. It does warn you, however that "mixing and matching" is
dangerous if they get out of sync.
> 
>   If GPT is fine, then is there anyway to migrate my existing array to a
> GPT partition table in the new box without having to install to new
> drives with a GPT table and then mount one of the existing drives to
> copy the data to the new array?

Use gfdisk, tell it to write a GPT. Just be careful it doesn't mess up
Grub2 for you ...

If you want to use new drives, once the system is up and running just
use mdadm --add or --replace.
> 
>   If these questions are already answered in a link somewhere, I
> apologize, I haven't found it. Thanks for any help/advise you can provide.
> 
Personally, I think your biggest problem is going to be grub. What I'd
do (and I'm going to have to do it sometime soon) is ...

Put the old drives on the new mobo. Boot using recovery media and make
sure the arrays are okay (shouldn't be a problem).

READ UP ON GRUB! Did I say that was going to be your biggest problem?

Fix grub to boot into your old Arch setup. It might be a good idea to
fit a new (old :-) disk solely for installing grub on until you're happy
everything is okay.

Your old system will now be up and running on the new mobo. Don't bother
switching your old drives to gpt, although you can, as I say, just use
gfdisk to write a GPT. Just be careful it doesn't mess up grub though ...

If you want to add new drives, you can use GPT on them, as I say, if
they're large disks, you'll need to use GPT.

Sounds like it's a small system, a home system? If you get new drives,
make sure they're proper raid drives, like WD Red. I've got Seagate
Barracudas, which was a mistake ...

Cheers,
Wol

Re: moving arrays from MBR part table install to GPT? Possible?

[David C. Rankin]

On 08/16/2015 07:27 AM, Wols Lists wrote:
> If you want to add new drives, you can use GPT on them, as I say, if
> they're large disks, you'll need to use GPT.
>
> Sounds like it's a small system, a home system? If you get new drives,
> make sure they're proper raid drives, like WD Red. I've got Seagate
> Barracudas, which was a mistake ...

Thank you for your response. It is my office server, but it runs on 2 1T drives 
(Carvair Black) Have had good experiences with them. I toss at least 1 barracuda 
in the trash every 3-4 months.

I'll stick with MBR and see how it goes. In that case I'll just boot the install 
media and assemble the arrays and see what I end up with.


-- 
David C. Rankin, J.D.,P.E.

Re: moving arrays from MBR part table install to GPT? Possible?

[Wols Lists]

On 17/08/15 07:28, David C. Rankin wrote:
> On 08/16/2015 07:27 AM, Wols Lists wrote:
>> If you want to add new drives, you can use GPT on them, as I say, if
>> they're large disks, you'll need to use GPT.
>>
>> Sounds like it's a small system, a home system? If you get new drives,
>> make sure they're proper raid drives, like WD Red. I've got Seagate
>> Barracudas, which was a mistake ...
> 
> Thank you for your response. It is my office server, but it runs on 2 1T
> drives (Carvair Black) Have had good experiences with them. I toss at
> least 1 barracuda in the trash every 3-4 months.

Well, my experience with Barracudas has been good - they were my
preferred choice of drive ...

You saying Black rang alarm bells for me, and I've just looked on my
favourite sales site - it says they are DESKTOP drives!

YOU NEED TO CHECK THEM OUT WITH SMARTCTL!

Check if they support ERC etc. The Barracudas I know don't, the Reds
various people have said they do. If the blacks don't support it, then
they'll let you down when you need it. You really don't want to go raid
5 or 6 with drives that don't support it. I want to go raid 5, which is
why I'm gutted to discover I'll have to replace my Barracudas. imho
they're decent serviceable drives ...
> 
> I'll stick with MBR and see how it goes. In that case I'll just boot the
> install media and assemble the arrays and see what I end up with.
> 
> 
Yup. No real point going gpt until you get to 3 and 4TB drives. Once you
can get linux running, it shouldn't care what sort of drives you have,
but if you read the gentoo wiki pages about installing on raid
(disclaimer, I wrote a decent chunk of it), you'll see what a pig it can
be getting as far as loading linux ...

Cheers,
Wol

Re: moving arrays from MBR part table install to GPT? Possible?

[Wilson, Jonathan]

On Mon, 2015-08-17 at 15:32 +0100, Wols Lists wrote:
> On 17/08/15 07:28, David C. Rankin wrote:
> > On 08/16/2015 07:27 AM, Wols Lists wrote:
> >> If you want to add new drives, you can use GPT on them, as I say, if
> >> they're large disks, you'll need to use GPT.
> >>
> >> Sounds like it's a small system, a home system? If you get new drives,
> >> make sure they're proper raid drives, like WD Red. I've got Seagate
> >> Barracudas, which was a mistake ...
> > 
> > Thank you for your response. It is my office server, but it runs on 2 1T
> > drives (Carvair Black) Have had good experiences with them. I toss at
> > least 1 barracuda in the trash every 3-4 months.
> 
> Well, my experience with Barracudas has been good - they were my
> preferred choice of drive ...
> 
> You saying Black rang alarm bells for me, and I've just looked on my
> favourite sales site - it says they are DESKTOP drives!
> 
> YOU NEED TO CHECK THEM OUT WITH SMARTCTL!
> 
> Check if they support ERC etc. The Barracudas I know don't, the Reds
> various people have said they do. If the blacks don't support it, then
> they'll let you down when you need it. You really don't want to go raid
> 5 or 6 with drives that don't support it. I want to go raid 5, which is
> why I'm gutted to discover I'll have to replace my Barracudas. imho
> they're decent serviceable drives ...

Thats not strictly true....

With a non TLER drive if a problem is found the drive might take a long
time to fix them internally and the device layer time out might be
exceeded.

With TLER the drive will always respond within, usually, 7 seconds.

I have the following embedded in a bash script:
> for x in /sys/block/sd[a-z] ; do echo 360 > $x/device/timeout ; echo -n "$x/device/timeout : " ; cat $x/device/timeout ; done
which is "/sys/block/sdX/device/timeout"

Now if the drive is TLER it will still respond in 7 seconds (either with
data, or an error - no change there), but if I should have any non-TLER
drives the device layer will now wait 360 seconds before timing out. (I
know, a long time which in most cases would cause frozen I/O, seemingly
hung... but hey, who knows the drive might eventually fix its self!)

This time out is just as true for non-raid as raid... if a non raid disk
takes longer to respond than the time out, you potentially lose the
drive... or you've just killed the last I/O commands to it and done a
hard reset. (That said, I think its up to the file system to then deal
with a timed out disk? should mdadm sit on top of the disk its
processing is "disk timed out, kick it".)




> > 
> > I'll stick with MBR and see how it goes. In that case I'll just boot the
> > install media and assemble the arrays and see what I end up with.
> > 
> > 
> Yup. No real point going gpt until you get to 3 and 4TB drives. Once you
> can get linux running, it shouldn't care what sort of drives you have,
> but if you read the gentoo wiki pages about installing on raid
> (disclaimer, I wrote a decent chunk of it), you'll see what a pig it can
> be getting as far as loading linux ...
> 
> Cheers,
> Wol
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>