headers
Axel Dörfler | 19 May 2003 20:21
Picon

Amiga RDB

Hi there,

some weeks ago, I promised to write an eMail about my findings when 
writing a scanner for the Amiga RDB partitioning scheme - so here it is 
:-)

1) the RDB (Rigid Disk Block) is the partition scheme identifier, it 
can be located within the first 16 blocks of a disk. It contains:
	- checksum
	- block size
	- bad blocks list
	- fs list
	- partition block list
	- drive geometry
	- drive and controller and -vendor information

The fs list allows for file systems to be placed on a special location, 
so that the operating system can boot from a non-native file system. Of 
course, that feature originated from AmigaOS, and therefore, should 
only be used with it.
We only need the partition block list from there.

2) The partition blocks can be located anywhere on the disk as long as 
they are addressable within 32 bit blocks (as defined in the RDB 
structure). Note, this limitation is only true for the partition 
descriptions, not for the partitions themselves.
A partition block contains:
	- checksum
	- a pointer to the next partition block
	- a disk environment structure
(Continue reading)

Permalink | Reply | 20 comments |
headers
Ingo Weinhold | 19 May 2003 21:48
Picon

Re: Amiga RDB

"Axel Dörfler" <axeld@...> wrote:
[...]
> Some general remarks:
> - the number of partitions is only limited by the amount of 
> addressable 
> blocks (so you could have 4 billions of them)
> - it's not intended to create sub partitions.
> 
> The disk geometry stuff, bad block lists, etc. are targeted towards 
> older SCSI drives, which we don't have to use, obviously. I don't 
> know 
> though, if they have to be maintained for compatibility - but I could 
> check that out.

Sounds `Mostly Harmless'. :-)
Save one point maybe: The possibility to define reserved blocks at 
beginning and end of the partition doesn't fit that nicely into the 
latest draft version of the DiskDevice API (nor into any of the earlier 
versions ;-). In order to still being able consider a partition a 
contiguous space a disk system resides on, it would be necessary to 
report only the non-reserved blocks as the partition space. But this is 
not so nice for DriveSetup, since it won't be able to display the 
reserved parts and the user might get a wrong impression about to which 
point a partition can be moved/resized.

Since the BDiskSystem::Validate*() calls will be used to ensure, that 
the new partition position and size will be OK, this won't have any bad 
consequences (let alone the slightly incorrect visualization), though. 
I could live with that.
(Continue reading)

Permalink | Reply | 19 comments |
headers
Axel Dörfler | 19 May 2003 23:25
Picon

Re: Amiga RDB

"Ingo Weinhold" <bonefish@...> wrote:
> Sounds `Mostly Harmless'. :-)

Right, also it combines most of the features found in other 
partitioning schemes.

> Save one point maybe: The possibility to define reserved blocks at 
> beginning and end of the partition doesn't fit that nicely into the 
> latest draft version of the DiskDevice API (nor into any of the 
> earlier 
> versions ;-). In order to still being able consider a partition a 
> contiguous space a disk system resides on, it would be necessary to 
> report only the non-reserved blocks as the partition space. But this 
> is 
> not so nice for DriveSetup, since it won't be able to display the 
> reserved parts and the user might get a wrong impression about to 
> which 
> point a partition can be moved/resized.
> 
> Since the BDiskSystem::Validate*() calls will be used to ensure, that 
> the new partition position and size will be OK, this won't have any 
> bad 
> consequences (let alone the slightly incorrect visualization), 
> though. 
> I could live with that.

I would actually appreciate if DriveSetup (or the appropriate add-on) 
could make the reserved space visible.
If you remember, we want to have a similar problem (at least I do ;-)) 
with our special partition used for RAID information etc. - something
(Continue reading)

Permalink | Reply | 18 comments |
headers
Ingo Weinhold | 19 May 2003 23:56
Picon

Re: Amiga RDB

"Axel Dörfler" <axeld@...> wrote:
> "Ingo Weinhold" <bonefish@...> wrote:
[...]
> > Save one point maybe: The possibility to define reserved blocks at 
> > beginning and end of the partition doesn't fit that nicely into the 
> > latest draft version of the DiskDevice API (nor into any of the 
> > earlier 
> > versions ;-). In order to still being able consider a partition a 
> > contiguous space a disk system resides on, it would be necessary to 
> > report only the non-reserved blocks as the partition space. But 
> > this 
> > is 
> > not so nice for DriveSetup, since it won't be able to display the 
> > reserved parts and the user might get a wrong impression about to 
> > which 
> > point a partition can be moved/resized.
> > 
> > Since the BDiskSystem::Validate*() calls will be used to ensure, 
> > that 
> > the new partition position and size will be OK, this won't have any 
> > bad 
> > consequences (let alone the slightly incorrect visualization), 
> > though. 
> > I could live with that.
> 
> I would actually appreciate if DriveSetup (or the appropriate add-on) 
> could make the reserved space visible.

Grrr... ;-)
(Continue reading)

Permalink | Reply | 17 comments |
headers
Axel Dörfler | 23 May 2003 02:50
Picon

Re: Amiga RDB

"Ingo Weinhold" <bonefish@...> wrote:
> "Axel Dörfler" <axeld@...> wrote:
> > I would actually appreciate if DriveSetup (or the appropriate add-
> > on) 
> > could make the reserved space visible.
> Grrr... ;-)

Hehe :-)

> > If you remember, we want to have a similar problem (at least I do ;
> > -
> > )) 
> > with our special partition used for RAID information etc. - 
> > something 
> > like this could also be handled as reserved space.
> That's something different I'd say. This special partition would 
> simply 
> be represented as, well, a special partition. In fact we may even 
> want 
> to allow moving and resizing for it.

Whoa, although I think you are right :-)

> > Anyway, for now, I don't think we have to deal with it - just 
> > report 
> > the accessible partition size and we're happy.
> I would actually rather like to do it right in the first place, i.e. 
> let's either decide in favor one way or another, but not for 
> preliminaries.
>
(Continue reading)

Permalink | Reply | 16 comments |
headers
Ingo Weinhold | 23 May 2003 16:38
Picon

Re: Amiga RDB

"Axel Dörfler" <axeld@...> wrote:
> "Ingo Weinhold" <bonefish@...> wrote:
[...]
> > > Anyway, for now, I don't think we have to deal with it - just 
> > > report 
> > > the accessible partition size and we're happy.
> > I would actually rather like to do it right in the first place, 
> > i.e. 
> > let's either decide in favor one way or another, but not for 
> > preliminaries.
> > 
> > The question that comes to my mind is, what function has this 
> > reserved 
> > space sticked to a partition? I can't really think of anything that 
> > makes much sense. And if that's the case, then I'm tending to favor 
> > dealing with it in the stepmotherly way outlined earlier, instead 
> > of 
> > extending the API just to include a nice handling for that 
> > particular 
> > partitioning scheme.
> 
> I don't even know if it is used by any file system, so maybe we 
> should 
> even think about wanting to support it :-)
> But I could at least check if any of my collection of hard disks do 
> that :-)

That would be great! When moving last year, I disposed a lot of things 
I had no longer need for. Among those also all my Amiga stuff (not 
light-heartedly though). So, I can't check it myself.
(Continue reading)

Permalink | Reply | 15 comments |
headers
Tyler Dauwalder | 24 May 2003 08:56

Re: Amiga RDB


On 2003-05-23 at 09:42:49 [-0700], Ingo Weinhold wrote:
> "Axel Dörfler" <axeld@...> wrote:
> > "Ingo Weinhold" <bonefish@...> wrote:
> [...]
> > > > Anyway, for now, I don't think we have to deal with it - just
> > > > report
> > > > the accessible partition size and we're happy.
> > > I would actually rather like to do it right in the first place,
> > > i.e.
> > > let's either decide in favor one way or another, but not for
> > > preliminaries.
> > > 
> > > The question that comes to my mind is, what function has this
> > > reserved
> > > space sticked to a partition? I can't really think of anything 
> > > that
> > > makes much sense. And if that's the case, then I'm tending to 
> > > favor
> > > dealing with it in the stepmotherly way outlined earlier, instead
> > > of
> > > extending the API just to include a nice handling for that
> > > particular
> > > partitioning scheme.
> > 
> > I don't even know if it is used by any file system, so maybe we
> > should
> > even think about wanting to support it :-)
> > But I could at least check if any of my collection of hard disks do
> > that :-)
(Continue reading)

Permalink | Reply | 14 comments |
headers
Ingo Weinhold | 24 May 2003 14:14
Picon

Re: Amiga RDB

Tyler Dauwalder <tyler@...> wrote:
> 
> On 2003-05-23 at 09:42:49 [-0700], Ingo Weinhold wrote:
> > "Axel Dörfler" <axeld@...> wrote:
> > > "Ingo Weinhold" <bonefish@...> wrote:
> > [...]
> > > > > Anyway, for now, I don't think we have to deal with it - just
> > > > > report
> > > > > the accessible partition size and we're happy.
> > > > I would actually rather like to do it right in the first place,
> > > > i.e.
> > > > let's either decide in favor one way or another, but not for
> > > > preliminaries.
> > > > 
> > > > The question that comes to my mind is, what function has this
> > > > reserved
> > > > space sticked to a partition? I can't really think of anything 
> > > > that
> > > > makes much sense. And if that's the case, then I'm tending to 
> > > > favor
> > > > dealing with it in the stepmotherly way outlined earlier, 
> > > > instead
> > > > of
> > > > extending the API just to include a nice handling for that
> > > > particular
> > > > partitioning scheme.
> > > 
> > > I don't even know if it is used by any file system, so maybe we
> > > should
> > > even think about wanting to support it :-)
(Continue reading)

Permalink | Reply | 13 comments |
headers
Axel Dörfler | 24 May 2003 17:03
Picon

Re: Amiga RDB

"Ingo Weinhold" <bonefish@...> wrote:
> > I know mphipps was an Amiga fan, but 
> > Amiga was really nothing more than a legend to me until I started 
> > working on this project. I've never even so much as seen an Amiga 
> > box...
> Ooohh! 8-O

I still have a working Amiga here, and MorphOS, which come with the 
Pegasos, is AmigaOS compatible.
I even still develop an application for it which should be finished 
soon! :-)

> ...
> Maybe it's a good idea to remove them from the BPartition anyway. 
> Mind 
> you, resizing/moving a partition will also always affect sibling 
> partitionable spaces (up to four in case of moving), which might be a 
> bit hairy to handle. Since the information the BPartitionableSpaces 
> provide are of interest only, if one is going to modify the partition 
> layout (and would only waste resources otherwise), it might make more 
> sense to retrieve them on request only. E.g. via a method 
> BPartition::GetPartitionableSpaces(BObjectList<BPartitionableSpace> *
> spaces). Or maybe even more consequent: 
> BPartition::GetPartitioningInfo(BPartitioningInfo *info), where 
> BPartioningInfo could not only know, which are the free spaces, but 
> also which space is assigned to which subpartition. This would also 
> solve the problem with the RDB's reserved space at the beginning/end 
> of 
> partitions, since the BPartitioningInfo would consider the complete 
> space occupied by a subpartition.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Axel Dörfler | 24 May 2003 17:33
Picon

Partition detection in the boot loader & kernel module discussion

Hi there,

I must admit that I was a) lazy, and b) wanted the partitioning scheme 
detection a bit faster for the boot loader (doesn't have to be, though, 
since I don't use any caching for the boot block - maybe OpenFirmware 
does (or the drive), though).

That's why I used the following API:
The partitioning modules only export one function (they are read-only):
	status_t scan_for_partitions(list *partitionList, int deviceFD);

On the other side, the boot loader exports:
	add_partition(list *partitionList, Partition *partition);

It's a very simple API as you can see, but it's also very powerful - 
the Partition objects can contain private data for the partitioning 
scheme used.
Currently, though, they are very simple objects that do exactly the 
minimum needed.

The advantages of this approach is that it is very simple and only 
requires a minimum API. The downside is that we would need to write 
extra (but very small and simple) partitioning modules for the boot 
loader (which are statically linked, though), and that it's not very 
nice for dynamic environments - but of course, add_partition() could 
check if it has to update an existing partition or not.
I think that the current kernel module API could be enhanced and 
simplified, though. The partitioning module should be able to keep some 
data between calls to partition_identify() and 
get_nth_partition_info(). It currently only has direct access to the
(Continue reading)

Permalink | Reply | 5 comments |

Gmane