partition structure/layout
in [Setup]
|
From: annalissa on 26 Dec 2009 22:43 Hi all, I have recently rewad in some tutorials that structure/layout of a linux partition is as shown here :- http://i529.photobucket.com/albums/dd339/aarklon/partition.png now is this same layout/structure used for both primary and logical partitions ?
From: Wanna-Be Sys Admin on 27 Dec 2009 06:36 annalissa wrote: > Hi all, > > I have recently rewad in some tutorials that structure/layout > of > a linux partition is as shown here :- > > http://i529.photobucket.com/albums/dd339/aarklon/partition.png > > now is this same layout/structure used for both primary and logical > partitions ? I can't understand exactly what you're asking? -- Not really a wanna-be, but I don't know everything.
From: annalissa on 27 Dec 2009 07:29 Wanna-Be Sys Admin wrote: > annalissa wrote: > >> Hi all, >> >> I have recently rewad in some tutorials that structure/layout >> of >> a linux partition is as shown here :- >> >> http://i529.photobucket.com/albums/dd339/aarklon/partition.png >> >> now is this same layout/structure used for both primary and logical >> partitions ? > > I can't understand exactly what you're asking? i mean this see:- http://www.csie.ntu.edu.tw/~pangfeng/System%20Programming/Lecture_Note_2.htm
From: philo on 27 Dec 2009 09:42 annalissa wrote: > Wanna-Be Sys Admin wrote: >> annalissa wrote: >> >>> Hi all, >>> >>> I have recently rewad in some tutorials that structure/layout >>> of >>> a linux partition is as shown here :- >>> >>> http://i529.photobucket.com/albums/dd339/aarklon/partition.png >>> >>> now is this same layout/structure used for both primary and logical >>> partitions ? >> >> I can't understand exactly what you're asking? > > i mean this > > see:- > http://www.csie.ntu.edu.tw/~pangfeng/System%20Programming/Lecture_Note_2.htm > Ok I see why you've asked the question and it looks like those "lecture notes" are wrong In them it states (quote): "In fact a symbolic link is very much like the "shortcut" in Windows. However, in Windows only file can have shortcut, not directory." (end quote) Don't know where they came up with that one as in Windows one can of course have shortcuts to folders. maybe you need to find a better tutorial
From: Aragorn on 27 Dec 2009 15:33
On Sunday 27 December 2009 04:43 in comp.os.linux.setup, somebody identifying as annalissa wrote... > Hi all, > > I have recently rewad in some tutorials that structure/layout > of a linux partition is as shown here :- > > http://i529.photobucket.com/albums/dd339/aarklon/partition.png > > now is this same layout/structure used for both primary and logical > partitions ? Yes, they have the same layout. The only difference between a primary and logical partition is that a primary partition has its partition table entries - i.e. the beginning and end of the partition - listed in the partition table of the master boot record of the hard disk it sits on, while a logical partition has its partition table entries listed in an extended partition container, which itself is a (special kind of) primary partition. The Linux kernel doesn't care about whether a partition is either primary or logical, or whethr it's an LVM logical volume for that matter. (Note: LVM "Logical Volume Management") is an abstraction layer on top of the existing partitioning layer.) See, the distinction between primary partitions and logical partitions in an extended partition container is a construct of the legacy real mode[1] BIOS and of DOS, because originally, the IBM PC and all derivative machines did not have (or support) hard disks, and DOS did not support them either. Then, with the IBM XT ("eXtended Technology") and as of DOS 3.00, support for hard disks was added to both the legacy BIOS and to DOS, but the original hard disks for such machines were rather small, e.g. 5 MB, 10 MB, 20 MB, 30 MB. The BIOS supported four primary partitions, of which one had to be marked "active", because the bootloader was a BIOS routine that would select the operating system to boot from one of the four possible partitions, and the "active" flag was the indicator to the BIOS which partition's bootsector to load into memory and pass control of the machine onto. The "active" primary partition was thus the one holding the operating system selected to boot at machine power-up, while the other primary partitions could eventually hold another operating system, and selecting which one to boot was then only a matter of marking the proper partition as "active". It was only later, with the introduction of the IBM AT ("Advanced Technology") and hard disks beyond 32 MB in capacity that the support for logical partitions in an extended partition container was added, because DOS could only handle a partition size of 32 MB - this would later be partly remedied in DOS 4.0 via a special trick, and would more appropriately be resolved in DOS 5.0. Logical partitions in the extended partition container cannot be marked "active", but the construct allowed DOS to use a primary partition - i.e. only the "active" one, as it could not access the other primary partitions on the same disk - plus an additional number of logical partitions in the extended partition container. Windows still abides by the legacy partitioning scheme and the concept of an "active" primary partition, in that Windows still makes use of the legacy BIOS bootloader code which reads the partition table of the first hard disk in the system - i.e. the hard disk marked in the BIOS as "bootable" - and then, via this partition table, locates the "active" primary partition and loads its bootsector (or "boot block", if you will) into memory, and then passes all control over the machine onto that piece of code, which is then the Windows NT bootloader. At that stage, the x86 processor[2] is still in real mode, and this is how real mode operating systems like DOS worked, i.e. by loading a piece of code into memory and passing all control of the machine onto that segment of code. The Windows bootloader program will then load another piece of code into memory, which would then be the bootstrap code of the Windows NT kernel, and it is only this bootstrap code that sets up the pagetables and switches the processor into protected mode. GNU/Linux on the other hand works quite differently. Although the real mode BIOS mechanism of loading an "active" primary partition's bootsector into memory can still be used - e.g. in the event that the GNU/Linux bootloader would reside inside a partition's bootsector, as opposed to the normal and recommended way of setting up a GNU/Linux system by having its bootloader reside in the master boot record of the hard disk marked in the BIOS set-up program as "bootable", hereby overwriting the legacy BIOS bootloader code which looks for an "active" primary partition. The GNU/Linux bootloader - itself also still a real mode program - will then directly load a kernel image into memory without looking at the partition type. This kernel image consists of real mode bootstrapping code and a compressed image of a protected mode kernel, and the real mode bootstrapping code then sets up the pagetables, switches the processor into protected mode and decompresses the actual protected mode kernel. And as such, the legacy principles which were only invented so as to allow a real mode operating sytem such as DOS or CP/M to boot on an x86 processor do not apply to GNU/Linux, nor to most other UNIX systems I know of - Minix and Microsoft's or SCO's Xenix would be exceptions since they were written for the 8086 architecture. [1] "Real mode" is the 8086-compatible mode of all x86 processors as of the 80286 on. All x86 processors are by design in real mode at power-up for DOS-compatibility, and as such, the legacy BIOS was still written as real mode code as well. XT and AT were only extensions to that old 16-bit real mode BIOS code. There are however protected mode BIOS versions[3] which already set up protected mode on the boot processor from within the BIOS - e.g. EFI, CoreBoot (formerly known as LinuxBIOS) - but these require a special version of the GRUB or LILO bootloaders[4], and a modified kernel image (without real mode bootstrapping code). However, at machine power-up, the processor is still in real mode by design, so the BIOS must first initialize protected mode. [2] During boot-up, only one processor is active - i.e. one CPU core on multi-core processor chips - and it is the kernel which, once protected mode has been entered, initializes the other processors and sets up the symmetric multiprocessing or NUMA[5]. [3] EFI ("Extensible Firmware Interface") and CoreBoot also allow for a different partitioning system, where you can have up to 128 primary partitions per hard disk, and where the special protected mode versions of LILO or GRUB actually become extensions to the BIOS. However, due to limitations in the Linux kernel, Linux can only handle 63 partitions in total on IDE disks accessed via the older ATA code or 15 partitions on SAS, SCSI, SATA and USB disks, and on IDE disks accessed via the newer /libata/ code. Among the computers which use an EFI BIOS are the Intel-based Apples and all machines with an Intel Itanium processor. Some motherboard manufacturers also support EFI or CoreBoot - Tyan used to support it but seems to have dropped that support again a few years ago - but only very few GNU/Linux distributions are actually built to be used with such firmware. Most are simply built for systems with a legacy BIOS. (Remember, you need a different version of either LILO or GRUB, and you need a different Linux kernel image.) [4] Non-x86 machines like the IBM PPC, Sun (Ultra)SPARC, SGI MIPS, Hewlett-Packard Alpha and PA-RISC, Intel Itanium et al already use such special versions of LILO or GRUB, since those processor architectures do not have a real mode. (Itanium does, but only via an x86-32 emulation mode, which must be explictly selected at boot time and/or enabled in the EFI firmware.) [5] NUMA stands for "Non-Uniform Memory Access" and is (on x86) the kind of multiprocessing found on AMD's 64-bit processors and on the newer Intel i7 systems, where you have multiple processor sockets with each socket having its own memory controller. As such, each socket - which houses a single- or multi-core processor chip - has its own local memory, while still being able to see all of the installed memory via access through the other processor sockets. This principle avoids the bottleneck of having a single memory controller for all processor sockets on the motherboard. -- *Aragorn* (registered GNU/Linux user #223157) |