Hi Jon!
flashjazzcat wrote:
We have the GUID partition table description here
http://en.wikipedia.org/wiki/GUID_Partition_Table. And we have the MBR format here:
http://en.wikipedia.org/wiki/Master_Boot_RecordBoth possibly contain a lot of information superfluous to our scheme.
There were times when I also checked these infos, but I wouldn't bother thinking about these 2 schemes anymore. GUID is nice, but far too complicated, and MBR is a real PITA. So I'd say we should just create our own, simple scheme.
I dug into my mailbox and read through the discussion I had with Sijmen in November 2008, concerning LBA support for the 5.1 MyIDE OS. Here's the (hopefully) last scheme we had and IIRC this is also implemented in my myidetool (not in the released versions, though).
Quote:
Partition table (10x8 bytes):
1x8 bytes for drive settings.
a1 a2 a3 a4 : size in LBA sectors
a5 : $51 '5.1' identification (IF>8 is new format, changed matthias)
a6 : Drive bits
a7 : Optionbyte
a8 : free
(reference to previous CHS: CL CH HD SC Dn DB IM IS)
1x8 bytes for image-setting.
b1 b2 b3 b4 : Start of Image location. LBA Sector L, M, H, U byte
=$00000000 then images are disabled/not set.
=$value, this limits the extension of logical drives.
b5 b6 : Numbers of Images L, H.
b7 b8 : free
8x8 bytes for drives.
c1 c2 c3 c4 c5 c6 c7 c8
c1 : density+drive# ($0x,SD+MD $2x,DD $8x,QD / DRIVES $x1-$x8)
c2 c3 c4 c5 : Partition location. LBA Sector L, M, H, U byte
c6 c7 c8 : Partition size L, M, H.
All sectors #0 are reserved.
The first 4 bytes (a1-a4) contain the total number of sectors of the drive (it's good to have this info because it can't be established reliably when a drive is connected to an USB adapter).
Byte 5 (offset 4) is used as a "version signature". Current MyIDE OS stores the number of partitions in it (0-8), we set it to $51 to distinguish between old and new layout (that's important for myidetool, I want to support both schemes in a single program).
The (optional) image space can hold a maximum of "number of images" (b5,b6) image-slots of 1041 sectors each.
The 8 partition blocks contain a combined density (128, 256, 512 bytes/sector) and drive-number (1-15) byte, together with 32 bit starting sector and 24 bit size info.
Both partitions and images contain a reserved sector 0 (this can be used to store image names and other stuff) which is usually not accessible through SIO. Therefore a 1040 sectors image uses 1041 sectors on disk, the same goes for partitions.
The basic layout on disk is as before (from low to high sectors):
partition table
partitions
image space
free space (for example for movies etc).
This was our idea back then, more or less just as a reference, it doesn't mean I want to keep it exactly this way
There are only a few things I'd really like to have in the new layout:
- most important: a way to distinguish between old and new partition-table layout (for example through byte 5 / offset 4)
- the total number of sectors of the disk
- a way to partition the disk into partition space / optional image space /optional free space
I also thought about adding support for more than 8-15 partitions (like the Black Box), so that the "image space" could be eliminated. But this would mean that we'd also need some new software to select/configure partitions and this software would never fit into the Atari OS. So it's better to keep the "image space" for people who like to store tons of disk images on their drive.
Now some thoughts about your suggestions:
Quote:
8-11: first addressable LBA block for partitions (1)
12-15: last addressable LBA block for partitions
Good idea!
As for image space: we could either add another 8 byte block (start/end), or combine this info into 3 4-byte blocks (as image_start would usually be partition_end+1 and thus be redundant).
Quote:
16: number of partitions
I guess we can remove this info.
Quote:
17-18: drive bits (?) (support for > 8 drives under SpartaDOS X)
Good question. Basically I'd say this info is redundant as it can be created from a drivenumber/active flag in the partition entries.
Quote:
19: option bits:
bit: function:
0: access mode (fast/careful)
1-7: reserved
Good question, again. Sijmen?
Quote:
starting at offset 32, we have the tables for each partition, arranged thus:
0-3: LBA start (32 bit)
4-7: # sectors (32 bit)
8-9: sector size (128 - 2048)
32bit sector numbers is a good idea (I guess we just used 24 back then because we wanted to fit all info into an 8 byte block).
But I'd just use a single byte for the sector size (for example meaning 2^x).
Quote:
10: drive number (do we need this if we have drive bits, or vice versa?)
11: active flag
12: bootable flag
We could combine this info into 1 byte, but since each entry will be 16 bytes (I'd strongly vote for aligning these structures at 2^x) we just might keep them separately.
On question though: what should the bootable flag be used for? I'd just skip it, even in the MBR/PC world only the (Win)DOS boot code uses this flag, all other bootloaders (like grub, lilo etc) ignore it and boot whatever partition you want.
A better alternative for selecting the boot-partition would be to store the boot-partition-number (1-15 or whatever) in the "main" block.
Quote:
An immediate improvement is to do away with or shorten the "signature" bytes at the start of the sector. This would allow the header record to fit into 16 bytes. In any case, all the subsequent tables will occupy 16 bytes each, yielding a total of 15 partitions with the shorter header record. Since SDX can support many drives, this seems reasonable.
With the addition of the image space stuff the header will be 32 bytes, but still 14 partitions is better than only 8 partitions before.
Quote:
Note the redundancy of having drive bits in the header record and drive numbers in the partition entries.
Yup, we should eliminate this redundancy
Quote:
Consider also that the partition table will be read into RAM on boot and stored for the duration (subject to changes by FDISK, when it will be re-written), hence it may occupy 1 page of RAM.
Not necessarily. At the cost of more program code space you can eliminate the buffer and interpret the data while you read the bytes from disk. Only when changing the partition table you'll need the full buffer, of course, but FDISK also needs some RAM, so this is no big deal IMO.
Quote:
Consider also the possibility of a back-up partition table (in LBA 1?).
This is also a good idea!
Jon, Sijmen, any ideas/suggestions/... ?
so long,
Hias