Greetings,
I'm seeing some weird issues surrounding the 2 terabyte limit on my 3ware (9590SE, PCI Express model) raid controller. Currently, the raid array is 6 x 500GB disks for a total of around 2.3 terabytes formatted. Looking at the documentation on the 3ware site, the raid card can handle a single partition over 2TB, but it still looks like fdisk fails to create a primary partition over the 2TB limit. I did resort to parted, and it creates a partition over 2TB. And, in fact, I can run mke2fs on this partition, and mount it. I also have an entry for this partition in the /etc/fstab file.
However, if I reboot the system, the partition fails to mount from the init scripts. If I comment out the /etc/fstab line, and run a mount command from rc.local, that works; however, the partition is now seen as a 259GB partition, and not the 2.3TB I originally had to start. I have the feeling the partition table is getting hosed on a reboot. Fdisk seems to handle the partition on the raid array just fine if it is a hair under 2TB, and from all the things I've read, it seems fdisk and other disk utilities still have real problems with partitions greater than 2TB (32-bit x 512-byte blocks, etc).
I guess I'm shocked. I figured this wouldn't be an issue as of 2006, but it still is..... anyone have any similar experiences? If so, any workarounds other than just stay at the 2TB limit?
Regards, Will
You can not have a DOS partition larger than 2Tb. parted will create one and tell the kernel about the size which works.... until you reboot and then the partition is 2Tb smaller than it should be because the partition table can not store the MSB of your partition size.
The solution is to use LVM or GPT partitions.
John.
W S wrote:
Greetings,
I'm seeing some weird issues surrounding the 2 terabyte limit on my 3ware (9590SE, PCI Express model) raid controller. Currently, the raid array is 6 x 500GB disks for a total of around 2.3 terabytes formatted. Looking at the documentation on the 3ware site, the raid card can handle a single partition over 2TB, but it still looks like fdisk fails to create a primary partition over the 2TB limit. I did resort to parted, and it creates a partition over 2TB. And, in fact, I can run mke2fs on this partition, and mount it. I also have an entry for this partition in the /etc/fstab file.
However, if I reboot the system, the partition fails to mount from the init scripts. If I comment out the /etc/fstab line, and run a mount command from rc.local, that works; however, the partition is now seen as a 259GB partition, and not the 2.3TB I originally had to start. I have the feeling the partition table is getting hosed on a reboot. Fdisk seems to handle the partition on the raid array just fine if it is a hair under 2TB, and from all the things I've read, it seems fdisk and other disk utilities still have real problems with partitions greater than 2TB (32-bit x 512-byte blocks, etc).
I guess I'm shocked. I figured this wouldn't be an issue as of 2006, but it still is..... anyone have any similar experiences? If so, any workarounds other than just stay at the 2TB limit?
Regards, Will
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
John Newbigin wrote:
You can not have a DOS partition larger than 2Tb. parted will create one and tell the kernel about the size which works.... until you reboot and then the partition is 2Tb smaller than it should be because the partition table can not store the MSB of your partition size.
The solution is to use LVM or GPT partitions.
Right.
The procedure should look something like this:
/sbin/parted /dev/yourdevice (parted) mklabel gpt (parted) print Disk geometry for /dev/etherd/yourdevice: 0kB - 3001GB Disk label type: gpt (parted) mkpart primary 0 3001G (parted) quit
Now build the filesystem. I normally use:
mke2fs -j -b 4096 /dev/yourdevice
(tap foot for a few minutes)
Now it should mount normally and you can uncomment out the entry for that device in /etc/fstab.
Hope that helps.
Cheers,
On Thursday 05 October 2006 12:58, chrism@imntv.com wrote:
John Newbigin wrote:
You can not have a DOS partition larger than 2Tb. parted will create one and tell the kernel about the size which works.... until you reboot and then the partition is 2Tb smaller than it should be because the partition table can not store the MSB of your partition size.
The solution is to use LVM or GPT partitions.
Right.
The procedure should look something like this:
/sbin/parted /dev/yourdevice (parted) mklabel gpt (parted) print Disk geometry for /dev/etherd/yourdevice: 0kB - 3001GB Disk label type: gpt (parted) mkpart primary 0 3001G (parted) quit
Now build the filesystem. I normally use:
mke2fs -j -b 4096 /dev/yourdevice
I'm sure you meant /dev/yourdevice1, assuming that the first gpt paratition of yourdevice is just appended a "1" like with old style dos partition (I've only done this with lvm whole disks).
/Peter
Peter Kjellström wrote:
On Thursday 05 October 2006 12:58, chrism@imntv.com wrote:
John Newbigin wrote:
You can not have a DOS partition larger than 2Tb. parted will create one and tell the kernel about the size which works.... until you reboot and then the partition is 2Tb smaller than it should be because the partition table can not store the MSB of your partition size.
The solution is to use LVM or GPT partitions.
Right.
The procedure should look something like this:
/sbin/parted /dev/yourdevice (parted) mklabel gpt (parted) print Disk geometry for /dev/etherd/yourdevice: 0kB - 3001GB Disk label type: gpt (parted) mkpart primary 0 3001G (parted) quit
Now build the filesystem. I normally use:
mke2fs -j -b 4096 /dev/yourdevice
I'm sure you meant /dev/yourdevice1, assuming that the first gpt paratition of yourdevice is just appended a "1" like with old style dos partition (I've only done this with lvm whole disks).
or 2 or 3 or ....
use the device name (without partition number) when you run parted. For mke2fs use the device name (including the trailing number) for the actual partition you want to fondle...whatever it happens to be on your system.
Cheers,
On Thu, 2006-10-05 at 13:35 +0200, Peter Kjellström wrote:
On Thursday 05 October 2006 12:58, chrism@imntv.com wrote:
John Newbigin wrote:
You can not have a DOS partition larger than 2Tb. parted will create
<snip>
Must a partition be used? Even before LVM, partitions are optional. Unless the "Grand Unified Boot Loader" has a problem wit it - I'm not that familiar with GRUB.
/Peter
<snip sig stuff>
-- Bill
I'll read up more on LVM and GPT partitions. Please forgive me for not completely RTFM'ing this thing. I was just at the end of my rope and frustrated and figured someone on the mailing list would have some sage advice. And it appears that is the case. :)
Thank you to all who replied.
Regards, Will
On 10/5/06, John Newbigin jnewbigin@ict.swin.edu.au wrote:
You can not have a DOS partition larger than 2Tb. parted will create one and tell the kernel about the size which works.... until you reboot and then the partition is 2Tb smaller than it should be because the partition table can not store the MSB of your partition size.
The solution is to use LVM or GPT partitions.
John.
W S wrote:
Greetings,
I'm seeing some weird issues surrounding the 2 terabyte limit on my 3ware (9590SE, PCI Express model) raid controller. Currently, the raid array is 6 x 500GB disks for a total of around 2.3 terabytes formatted. Looking at the documentation on the 3ware site, the raid card can handle a single partition over 2TB, but it still looks like fdisk fails to create a primary partition over the 2TB limit. I did resort to parted, and it creates a partition over 2TB. And, in fact, I can run mke2fs on this partition, and mount it. I also have an entry for this partition in the /etc/fstab file.
However, if I reboot the system, the partition fails to mount from the init scripts. If I comment out the /etc/fstab line, and run a mount command from rc.local, that works; however, the partition is now seen as a 259GB partition, and not the 2.3TB I originally had to start. I have the feeling the partition table is getting hosed on a reboot. Fdisk seems to handle the partition on the raid array just fine if it is a hair under 2TB, and from all the things I've read, it seems fdisk and other disk utilities still have real problems with partitions greater than 2TB (32-bit x 512-byte blocks, etc).
I guess I'm shocked. I figured this wouldn't be an issue as of 2006, but it still is..... anyone have any similar experiences? If so, any workarounds other than just stay at the 2TB limit?
Regards, Will
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- John Newbigin Computer Systems Officer Faculty of Information and Communication Technologies Swinburne University of Technology Melbourne, Australia http://www.ict.swin.edu.au/staff/jnewbigin
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 10/5/06, W S ws3reg@gmail.com wrote:
I'll read up more on LVM and GPT partitions. Please forgive me for not completely RTFM'ing this thing. I was just at the end of my rope and frustrated and figured someone on the mailing list would have some sage advice. And it appears that is the case. :)
You do need gpt in this case, and from my testing on CentOS 4 x86_64, it will take your ext3 partitions to 4TB.
LVM is not related to this issue.
I did, in fact, go with GPT disk labeling. It now survives a reboot just fine.
On 10/6/06, Francois Caen frcaen@gmail.com wrote:
On 10/5/06, W S ws3reg@gmail.com wrote:
I'll read up more on LVM and GPT partitions. Please forgive me for not completely RTFM'ing this thing. I was just at the end of my rope and frustrated and figured someone on the mailing list would have some sage advice. And it appears that is the case. :)
You do need gpt in this case, and from my testing on CentOS 4 x86_64, it will take your ext3 partitions to 4TB.
LVM is not related to this issue.
-- Francois Caen, RHCE, CCNA SpiderMaker, LLC _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos