also @ TechSpot: Rumor: AMD "Piledriver" FX CPU production to begin Q3 2012

TechSpot

Linux Max Partitions....63???

Discussion in 'The Alternative OS' started by khakisheep, Sep 23, 2005.

Thread Status:
Not open for further replies.

  1. khakisheep Newcomer, in training

    Hi all,

    Need to clarify something. On another forum I'm encountering some people saying that with Linux it can only handle and or create and manage a maximum of 63 partitions? I am having trouble grasping this mystical '63' number I keep seeing. Can anyone here confirm this and explain it? And is there a workaround. I've always known and believed I could create as many logical partitions as I wanted, maxing at like 255 or something. Is this a Linux exclusive situation or what?

    Users at other forum weren't too helpful with this matter, they basicly said try to push past 63 and see what happens. Well in a perfect world I could, but I have a deadline for this project at work and cannot get to 63 and then have my project flounder and die. I need work-arounds, confirmations etc, if anyone can. Many thanks ahead of time.

    Someone mentioned creating individual kernel modules as a workaround to creating hundreds of partitions for my project. Can anyone shed light on this as well.

    Thanks for reading.
    khakisheep, Sep 23, 2005
    #1

  2. jobeard TechSpot Ambassador

    the answer is likely to be in the size of the programming structure that holds the memory copy of the actual partition table.
    remember, each physical HD has one partition table holding all the mappings for that HD.
    this will result in a hierarchy of HD[x]->part[y]->filesys-info

    such limits are ususally powers of 2, so expect 32,64,128, ...
    If you have access to Lunix source, you can find the answer there.
    jobeard, Sep 23, 2005
    #2

  3. jobeard TechSpot Ambassador

    Linux manpage 8 fdisk clearly states
    IDE max 63, SCSI max 15,
    see also /usr/src/linux/Documentation/devices.txt
    jobeard, Sep 23, 2005
    #3

  4. Mictlantecuhtli TS Special Forces

    Taken from Linux kernel documentation (not sure how up to date it is):

    Code:
    3 block	First MFM, RLL and IDE hard disk/CD-ROM interface
		  0 = /dev/hda		Master: whole disk (or CD-ROM)
		 64 = /dev/hdb		Slave: whole disk (or CD-ROM)

		For partitions, add to the whole disk device number:
		  0 = /dev/hd?		Whole disk
		  1 = /dev/hd?1		First partition
		  2 = /dev/hd?2		Second partition
		    ...
		 63 = /dev/hd?63	63rd partition

		For Linux/i386, partitions 1-4 are the primary
		partitions, and 5 and above are logical partitions.
		Other versions of Linux use partitioning schemes
		appropriate to their respective architectures.
    The documentation also includes only ten IDE hard disk / CD-ROM interfaces, so the devices would go from hda to hdt only (master & slave).
    Mictlantecuhtli, Sep 24, 2005
    #4

  5. tdeg Newcomer, in training

    I guess the big question is why do you need more than 63 partitions?

    Can't you just use a few partitions and then different mount points?

    Are you trying to have a computer with every type of possible filesystem or something?
    tdeg, Sep 28, 2005
    #5

  6. khakisheep Newcomer, in training


    I suppose I could have just a few partitions and then different mount points...but again, this is my first experience with Linux. And my reason for coming to these forums was to get advice on how to go about this task and learn from people who may already know how to do what I'm attempting to do. So again, my task is a SINGLE HDD with the possibility of installing/booting an individual set of software drivers for 150+ motherboards.
    They cannot annoy and touch one another, my only thoughts were seperate partitions with seperate installations of an OS.

    I don't care how its done, or what methods I have to use. For ease on our technicians I'm trying to accomplish this with windows but not having any luck. Linux seems to be offering me the solutions I need but straight answers are what I'm needing but aren't receiving. I'm attempting to research all suggestions that you guys mention, but for a noob its proving difficult at best to answer questions of why I don't try this, when its not an option I ever knew existed.

    If you have a suggestion PLEASE by all means continue to post them.
    Examples are nice! Here's something that might work, you may want to read about this and try this. etc. etc.

    Thanks again for continued interest and help. I need it
    khakisheep, Sep 28, 2005
    #6

  7. Nodsu Newcomer, in training

    How about some virtual machine solution like VMWare or xen?

    Or mounting files (loop device) as / for different incarnations of Linux at boot?
    Nodsu, Sep 28, 2005
    #7

  8. jobeard TechSpot Ambassador

    There are TWO factors for Linux hardware support:
    1) the kernel it self (line <K> of the lilo.conf below)
    2) and the hardware specific drivers in the subdirectories of /sys.
    All the binary executables will support any Intel platform, eg: /bin/*

    The lilo/grub loaders will present a choice of kernels to load and you
    can create a list of possibilities.
    OR
    It's your experiment so I will only suggest that if you create a technique
    to overlay the entire contents of /sys and /boot for each configuration,
    you might be able to bootstrap into the final environment of your choice.
    a) boot a simple, constant system
    b) overylay /sys and /boot with X
    c) reboot into X

    I would think you'd need an environment like
    simple--->HD<-----TestSystem
    and you would need to cable/recable the HD between systems, making
    an external HD (maybe SCSI) a natural choice.

    My lilo.conf
    ==============
    boot = /dev/hda2
    delay = 200
    timeout = 400
    prompt
    vga = normal
    read-only
    map=/boot/map
    install=/boot/boot.b
    image = /boot/vmlinuz-2.2.5-15 <K>
    label = linux6.0
    root = /dev/hda2
    other = /dev/hda1
    label = Win98
    table=/dev/hda
    ==================
    jobeard, Sep 28, 2005
    #8
Thread Status:
Not open for further replies.