I have been asked to provide desired partition sizes for RHEL 5.x - no
problem I can do that.
This is to create VM's to be run on ESX.
But I have been asked which should be logical and which should be
extended.
And the guy who asked has now unavailable.
Logical and extended? MS?
Is this a normal question?
TIA
Syd
GNU/Linux doesn't care about whether partitions are primary or extended,
or logical volumes. It handles all of them equally well. ;-)
The primary versus extended is a legacy thing, dating back to the days
of DOS, and for most x86 hardware still required because of the legacy
real mode BIOS code. The legacy partition table in the master boot
record can only hold four entries, and so if you need more than four
partitions, one of those four entries must be an extended partition
container, which can then further be divided into logical partitions,
with their own partition table inside the extended partition container.
DOS could only handle one primary partition per disk, and so this
partition had to be marked "active"/"bootable", and this would be the
partition whose bootsector got read into memory by the legacy BIOS and
the legacy DOS-style bootloader code in the MBR.
GNU/Linux doesn't work like that. The GNU/Linux bootloaders LILO and
GRUB do not boot the Linux kernel by loading a partition bootsector
into memory, but rather load the kernel image directly. LILO does this
via a hardcoded binary LBA offset, GRUB does it via a real mode
filesystem driver for the "/boot" partition, but whether this partition
is primary or logical is of no concern.
The only problem you may encounter - with GRUB, not with LILO - is that
the filesystem holding the kernel images - whether it is a
separate "/boot" or whether this lives on the root filesystem itself -
may not be a logical volume (as in "logical volume manager"), because
LVM is an abstraction layer above that of the physical partitioning
layout, and GRUB doesn't have a way to read those. LILO will still
work under those circumstances because it hardcodes the offset and
doesn't read any filesystems.
(Most GNU/Linux distributions now offer GRUB as the default bootloader
as it offers more functionality and flexibility than LILO.)
--
*Aragorn*
(registered GNU/Linux user #223157)
*NONE*. In an ESX environment, it's actually noticeably easier to set
up all partitions as primary or as additional disks. The only reason
to do LVM, in this case, is to test a layout you plan to use
elsewhere, or to provide LVM snapshotting.
For real hardware, extended partitions get you past the 4 partitions/
apparent disk limitation. LVM gets you snapshotting and what behaves
much like RAID 0 in a more flexible format. But neither is
particularly useful in virtualization, because your disk access and
availability is bound by the emulator and the virtualization server's
disk setups. Almost all sophistication inside the virtualization
environment is a complete waste of time. (OK, LVM Snapshots have a use
for backup access.)
Thanks for all you comments BTW
> On 14 Dec, 21:14, Bill Marcum <marcumb...@bellsouth.net> wrote:
>> On 2009-12-14, syd_p <sydneypue...@yahoo.com> wrote:> Hi,
>>
>> > I have been asked to provide desired partition sizes for RHEL 5.x -
>> > no problem I can do that.
>> > This is to create VM's to be run on ESX.
>> > But I have been asked which should be logical and which should be
>> > extended.
>> > And the guy who asked has now unavailable.
>>
>> > Logical and extended? MS?
>> > Is this a normal question?
>>
>> An extended partition contains logical partitions. There is usually
>> no more than one extended partition on a hard drive. Extended and
>> logical partitions exist because a hard drive can not have more than
>> 4 primary partitions. In some operating systems the boot partition
>> must be a primary partition, but not in Linux.
>
> Ah I think I get it - I had assumed that no more than 4 primary
> partitions was a restriction from MS.
Well, yes and no... It's a restriction of the legacy real mode BIOS
code and MS-DOS. Because of the required backward compatibility with
DOS and the DOS-based Windows versions - which were still being sold up
until the year 2000 - this is still being used today.
By design, any x86 processor - even x86-64 - default to the
DOS-compatible real mode at power up, and usually it's the
bootstrapping code in the operating system's kernel which sets up the
pagetables and descriptor tables and switches the processor in
protected mode.
On the other hand, machines with an EFI BIOS - such as the Intel-powered
MacIntosh - or a CoreBoot (a.k.a. LinuxBIOS) have a BIOS which switches
the processor into protected mode itself. Such systems then require a
special protected mode bootloader and a kernel without real mode
boostrapping code. Such machines can make use of a whole new
partitioning system which allows for up to 128 primary partitions per
disk.
> I thought that partitions could be just ext3 - in that same way that
> you can have as many solaris slices as you want with sol 10 and sparc.
Ehm, you are confusing a few things. An extended partition is not the
same thing as ext3, which is a *filesystem.* Also, Solaris - at least
on its native (Ultra)SPARC hardware - uses a kind of EFI BIOS, as do
MIPS machines with IRIX and machines with an Intel Itanium processor.
> So I think now that the no more than 4 primary partitions is a
> restriction with intel and the scsi drives that you can use with
> intel.
> Am i on message now?
Not yet. ;-) The "no more than 4 primary partitions" is a limitation of
the x86 platform with a legacy BIOS. Non-x86 machines or x86 machines
with EFI or CoreBoot can use 128 primary partitions.
That said, there is an additional limitation for SAS/SCSI/SATA/USB hard
disks and PATA hard disks addressed via the new /libata/ drivers, i.e.
all disks that appear as "/dev/sd?". Such disks or even arrays of
disks can only make use of 15 partitions per disk, even if there are
more partitions than that - primary or extended is irrelevant. This
limitation exists because of programming confinements in the Linux
kernel SCSI midlayer, but it has nothing to do with the SCSI hardware
itself, whether used on x86 or on another hardware platform.