[lkml]   [2003]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Disk Geometries reported incorrectly on 2.6.0-testX
    On Sun, Nov 30, 2003 at 01:48:56PM +0000, John Bradford wrote:
    > Quote from Sven Luther <>:
    > > On Sun, Nov 30, 2003 at 10:40:25AM +0000, John Bradford wrote:
    > > > * All partition information stored in one partition table
    > > >
    > > > Linked lists make re-arranging partitions, and backing up the
    > > > partition table more difficult.
    > >
    > > I don't agree here. You just follow the linked list and make the backup,
    > > which is one more reason for having the save/restore mechanism in the
    > > per partition table code, which knows how to read/write the partition
    > > table anyway. Also, mostly the linked list is found in a chunk of the
    > > disk which you can easily backup with dd. The amiga scheme has both
    > > information about the number of sectors which can be used in the linked
    > > list, as well as the last used sector.
    > I must admit, I haven't looked at every single partitioning scheme we
    > support in detail.
    > Also, my method of working may not be typical, in that I don't
    > generally partition all of the space on a disk, just because it's
    > there. This came up on LKML a few months ago, in a discussion about
    > re-sizing filesystems in which I noted that the common case of wanting
    > to shrink a partition containing a filesytem with free space on it,
    > just to allow experimentation with a new filesystem, can be completely
    > avoided in many cases, simply by partitioning only the space you
    > expect to need from the begining.

    Sure, but you don't always know about this at the begining.

    > > Also, with a linked list, you can maintain two or more partition tables
    > > on disk, thus making an on-disk backup easy. When you write a new
    > > partition table, you write it on other sectors than the first one, and
    > > then update the root pointer. You can then later go back to the old
    > > partition table by just restoring the root pointer or something such.
    > I can see that linked-list partition tables have uses, but I think
    > that their disadvantages outweigh their advantages here - if some
    > partitioning data is stored at non-fixed locations on the disk,
    > overwriting a partition can destroy partitioning data for several
    > other partitions, whereas a dedicated area for partition data isn't
    > vulnerable to this.

    Well, i don't know about macos, or other linked partition tables, but in
    the amiga case, you just use a chunk of the disk at the begining to
    store the partition entries in (each partition correspond to a 512 byte
    sector). The RDB (the root of the partition tree) contains information
    about what sector are allocated to the partition table, and what can be
    used for other stuff. In the libparted case, i just made the partition
    table not available to put partitions in it, and there can not be
    possible overwriting, either by parted or by kernel access, since both
    respect the reserved space. Furthermore the RDB can be found in any of
    the 16 first sectors of the disk, and i put it in sector 2 by default,
    so as to not loose it when someone stupidly writes an MBR on top of it
    (like i did when playing with beta debian-installer and evil autopartkit
    and a messed up console). Historicaly there were also other stuff stored
    in the linked list on amigaos, like a badblock list, as well as
    filesystem drivers.

    > > Also, it allow you flexibility with the amount of partitions you can
    > > use, as you could have potentially have any number of partitions you
    > > like (upto 2^30 or such).
    > Again, I can see that large numbers of partitions might have uses, but
    > in my experience 4 is a real limitation, whereas 8 or 16 wouldn't be.

    I routinely have more than 8 partitions in any case. With the large
    disks we have today, i guess it would be quite easy to have more than 16
    of them too, altough i don't remember having them (i had an hda15

    > Where, say > 128 partitions are needed, linked-lists are probably a
    > win, but my requirements are for a simple, reliable partitioning
    > scheme which supports large partitions, and allows us to completely
    > remove CHS code from the kernel. I don't think we currently support
    > one.

    What has linked lists to do with CHS ? These are fully orthogonal

    And consider the simplest of linked list, the one were the next block is
    the block immediately after the current one. You would have a root block
    with details about the disk, information about the area reserved and
    such, and then a simple 0xffffffff (or whatever) terminated array or
    something. You could even keep the linked list scheme for flexibility, but
    make it linear. Ideally, you would have two lists (or more) for backup,
    and the root block would contain the extent of sectors reserved for this
    usage (128Ko on larger disks maybe ?) as well as the highest used block
    of this, so you can easily back it up with dd or something.

    Alternatively you could have replications of this table at regular
    intervals of the disks or something.


    Sven Luther
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:59    [W:0.026 / U:25.792 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site