Dell Perc 6 disk geometry problem with RAID5 (both 6.3 final and 7.0 RC1)

David Wood david at wood2.org.uk
Sun Jan 20 10:54:37 PST 2008


Hi there,

In message <20080120175819.GA52965 at owl.midgard.homeip.net>, Erik 
Trulsson <ertr1013 at student.uu.se> writes
>On Sun, Jan 20, 2008 at 04:48:56PM +0000, David Wood wrote:
>> In message <9c1614e00801200608k49195944mf241b7b0aa6a48 at mail.gmail.com>,
>> Aldas Nabazas <freebsd.stable1 at gmail.com> writes
>>> We bought a new Dell PowerEdge 2950III with Perc 6/i and have the disk
>>> geometry problem using 6.3 final or 7.0 RC1. Seems that we are not alone at
>>> least one guy has similar problem reported earlier:
>>> 
>>>http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2008-01/msg0
>>>0506.html
>
>I do not know if the mfi(4) driver has any problems with large disks, but it
>is however well known that fdisk(8) and bsdlabel(8) (the tools normally used
>to partition disks) have problems with volumes larger than 2TB.
>
>If you want to use volumes larger than 2TB then gpt(8) is the recommended
>way to partition the disks.  It is however doubtful if the BIOS in your
>system will allow you to boot from a gpt(8) parttioned volume which is
>best solved with having a separate - smaller - boot volume where the OS
>itself is installed.

Erik's reminder is timely for those with >2TB volumes.

You must use gpt and not fdisk on any disk, be it a single drive (in the 
future, at least!) or a virtual disk on a RAID setup that are bigger 
than 2TB. It may be wise to use gpt on any virtual disk that you might 
grow to 2TB or larger in the future, so long as you're not needing to 
boot from that virtual disk.

fdisk will not work properly with 2TB and larger volumes - the MBR / 
partition table setup can't cope with these large volumes.


You can't boot from a GPT volume - that's a limitation of the BIOS 
architecture. There is some thought about using EFI on x64 hardware in 
the future (EFI is used on ia64 hardware; GPT is part of EFI), but we're 
not there yet. This isn't just about adding GPT support to the BIOS - 
the whole BIOS setup is wedded to MBR.

If you need to boot from a >2TB array, create two virtual disks - one 
smaller than 2TB to boot from (and use MBR on that), then the residue 
can be GPT.


However, Erik's 6*146 is only 846GB, which should be fine as an MBR / 
partition table volume (and the use of RAID 5 means you only have 5*146 
usable in any case). The referenced problem on freebsd-questions sounds 
like a failure to use GPT, but Erik's problem sounds different.



When I said there was nothing relevant waiting for MFC, I was aware of 
the change that Tom mentioned, but that seems to be about Dell PERC 6 
being identified as such rather than a MegaRAID. It doesn't seem that it 
will change the behaviour of the driver in any way.

There's another change in -CURRENT to do with the log buffer; again, 
that doesn't seem to be relevant here.

Nevertheless, if one or both of these changes are felt stable enough to 
be MFCed to RELENG_7 and ideally RELENG_7_0, that would be good. I do 
have my doubts as to whether agreement will be got to merge them to 
RELENG_7_0 at this stage, however.


Erik - can you post dmesg output, details on how you've arranged the 
physical disks into virtual disks, exactly how you get an anomalous 
result, and why you think what you're seeing is wrong.



I went to look at HP, and I wasn't particularly happy with their 
offering. The Proliant DL380 G5 isn't a bad machine - but it uses 2.5 
inch disks, and I prefer the 6 x 3.5 inch option available with the Dell 
Poweredge 2950. With the current state of development of disks and my 
requirement for a high capacity array, a 3.5 inch based machine is more 
suited to my needs. I also prefer the way that you order a Dell.

I do hope we can reassure ourselves over the PERC 6/i. The PERC 5 series 
seems to have an excellent reputation under FreeBSD, and hopefully the 
newer PERC 6 series will soon get the same excellent reputation.



Best wishes,




David
-- 
David Wood
david at wood2.org.uk


More information about the freebsd-stable mailing list