Horst wrote,
> Neil, thanks for expanding on this -- I am amazed to hear that the
>crucial info about how my hdb is divided into 13 partitions (ext2, ext3,
>FAT16, FAT32) --fits in just those 64 bytes ... (that must have been
>designed before bloatware, when 32kb of RAM were enough to go to the moon :-)
Well...sort of. The master boot record only has room to describe four
partitions. At most three of those are actual user partitions--the fourth
is an "extended partition", which can contain many sub-partitions. It's
formatted as a chain of partition tables: The first block of the extended
partition contains another parition table with two entries, one of which
points to a user parition, and the other points to yet another partition
table with two entries...repeat as necessary.
It's not surprising that a partition table entry only takes 16 bytes,
since it doesn't take much information to describe a partition. A
partition entry contains the starting sector of the partition (stored both
as a cylinder/head/sector number and a linear sector number), the
partition size (stored both as the ending cylinder/head/sector and as a linear
sector count), the bootable flag, and the filesystem ID byte.
>> If you restore to a partition that's too large, the restored partition may
>> mount OK, but you'd only be able to access the restored size...the rest of
>> the space would be unavailable.
>
> That would be OK if there are no other risks? -- as I recall, depending
>on partition tool and geometry, one doesn't always get the desired size so
>a small dead area at the end is no biggie if there is no other potential
>harm?
I dunno...it sounds like it OUGHT to work, but I recommend experimenting
first, with data that you can afford to lose.
- Neil Parker
_______________________________________________
EuG-LUG mailing list
[EMAIL PROTECTED]
http://mailman.efn.org/cgi-bin/listinfo/eug-lug
