Limitation of partition's capacity with Fdisk ?
Regis
I got a working station under Debian 5.0 with SAS internal controler with a "big" external Raid6's rack of 16x 1To/disk view as two
volumes /dev/sdd and /dev/sde. (/dev/sda,sdb,sdc are internal system's disks)
My prb. is that fdisk don't accept to create partition greater than 267348 cylinders! on /sdd or /sde???
I'll try to use the full space of the volume (env.6To) in just one partition. (sdd(6To)=255heads,63sectors/track,729325 cylinders)
But for "end" fdisk propose only [1-267348]range?
Here's log.
-----------------------------------------------------------------------------------------------------------
sion@calc1:~$ sudo fdisk /dev/sdd
The number of cylinders for this disk is set to 729325.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
(After creating the max. single primary partition possible...)
Command (m for help): p
Disk /dev/sdd: 5998.9 GB, 5998903296000 bytes
255 heads, 63 sectors/track, 729325 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x4fc14bf0
Device Boot Start End Blocks Id System
/dev/sdd1 1 267349 2147480811 83 Linux
Command (m for help):q
------------------------------------------------------------------------------------------------------------------------
any idea?
Regis
David W. Hodgins
> I'll try to use the full space of the volume (env.6To) in just one partition. (sdd(6To)=255heads,63sectors/track,729325 cylinders)
> But for "end" fdisk propose only [1-267348]range?
A dos style mbr only uses 32 bits for the sector numbers, so it's
limited to a max of 2 Tib.
Use a gpt disk. http://en.wikipedia.org/wiki/GUID_Partition_Table
The parted program can work with gpt disks (fdisk cannot) using
"mklabel gpt".
Regards, Dave Hodgins
--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
Nico Kadel-Garcia
wrote:
> On Thu, 10 Dec 2009 10:01:37 -0500, Regis <rs...@univ-littoral.fr> wrote:
> > I'll try to use the full space of the volume (env.6To) in just one partition. (sdd(6To)=255heads,63sectors/track,729325 cylinders)
> > But for "end" fdisk propose only [1-267348]range?
>
> A dos style mbr only uses 32 bits for the sector numbers, so it's
> limited to a max of 2 Tib.
>
> Use a gpt disk. http://en.wikipedia.org/wiki/GUID_Partition_Table
> The parted program can work with gpt disks (fdisk cannot) using
> "mklabel gpt".
>
> Regards, Dave Hodgins
I'm not shocked: fdisk is an ancient and venerable tool, but limited.
And not even all RAID *controllers* can handle RAID sets over 2
Terabytes due to 32 bit limits: I ran into that little issue about 5
years ago when I was stuffing 300 Gig disks into a fiber-channel array
for a render farm. It's not surprising that the OS tools are running
into problems.
And at least you're at the latest stable Debian. I'd hate to have to
do it with RHEL, which is nearly 3 years old.
Regis, you *are* using a 64-bit server and operating system, right?
Regis
Thanks Dave,
I'll have a look on Wiki to see how to configure a "gpt" disk!
Yes Nico, It's a HP Z800 with two Xeon E5520, MEM=16GB SAS/Disk, running with OS Debian Lenny 5.0 Amd64(EMT64)
Kernel 2.6.26-2-amd64 #1 SMP.
The rack (Raid6) is a Infortend/Transtec EonStor series (SAS/Sata)
Regards
Régis
spi...@freenet.co.uk
> Thanks Dave,
> I'll have a look on Wiki to see how to configure a "gpt" disk!
Hardly any need to go that far.
You just use parted as suggested and set the partition table type to gpt.
Then it's just a matter of telling it what partitions you want as normal.
(the command if you use the CLI tool is mklabel)
All of the commands are listed with help <command> from the prompt.
--
| spi...@freenet.co,uk | "Are you pondering what I'm pondering Pinky?" |
| Andrew Halliwell BSc | |
| in | "I think so brain, but this time, you control |
| Computer Science | the Encounter suit, and I'll do the voice..." |
spi...@freenet.co.uk
> I'm not shocked: fdisk is an ancient and venerable tool, but limited.
> And not even all RAID *controllers* can handle RAID sets over 2
> Terabytes due to 32 bit limits: I ran into that little issue about 5
> years ago when I was stuffing 300 Gig disks into a fiber-channel array
> for a render farm. It's not surprising that the OS tools are running
> into problems.
>
> And at least you're at the latest stable Debian. I'd hate to have to
> do it with RHEL, which is nearly 3 years old.
Pah, I ran into that problem 5 years ago. Parted solved it, only fdisk
failed. I'm slightly surprised no-one's thought to add gnu parted partition
support (which I think gpt stands for) into fdisk yet, but it's been a known
fix for at least that long.
Nico Kadel-Garcia
> And verily, didst Nico Kadel-Garcia <nka...@gmail.com> hastily babble thusly:
>
> > I'm not shocked: fdisk is an ancient and venerable tool, but limited.
> > And not even all RAID *controllers* can handle RAID sets over 2
> > Terabytes due to 32 bit limits: I ran into that little issue about 5
> > years ago when I was stuffing 300 Gig disks into a fiber-channel array
> > for a render farm. It's not surprising that the OS tools are running
> > into problems.
>
> > And at least you're at the latest stable Debian. I'd hate to have to
> > do it with RHEL, which is nearly 3 years old.
>
> Pah, I ran into that problem 5 years ago. Parted solved it, only fdisk
> failed. I'm slightly surprised no-one's thought to add gnu parted partition
> support (which I think gpt stands for) into fdisk yet, but it's been a known
> fix for at least that long.
Well, fdisk might work well with the most venerable of controllers:
not everyone is going to have 2 TB disks to support yet! Not upgrading
such core utilities until you have to is a basic step to preserve
stability. And the friendly installers would have to be rewritten to
use parted instead of fdisk, which is a tricky bit of work. It
certainly seems worth doing, as gpt partition tables become more
reliable or even universally available.