Hyperion Entertainment Message Boards

When adding multiple partitions with the same volume name can a "RAID" header check be performed?
Bootstrapping the system, "RAID" partitions can be merged using a pool for each volume?

Also the option when creating a "RAID" partition for the parts to be "mirror" and "append" sequence ID marked.
Alternate sizing option ( mirror an existing partition / append existing).

This would be a helpful step towards building ZFS style feature support as far as my limited understanding indicates.

In mirror/append cases the sequence ID generally orders blocks and is inverse priority (filesystem optimization hint.)

How to build a single volume of many parts to be handled by a volume pool mechanism?

OpenZFS and Solaris ZFS documentation may help model this for an Amiga system raid framework?

CANCELLED: I'be found another way to set this up without OS component modifications.

My first thought is : "Why bother?"

There may be some software RAID support out there, but it's not part of the OS and not likely to be. You can buy a hardware RAID system (NAS) for less than the cost of an Amiga anyway.

So who or what exactly would benefit from these additions to MTB?

ZFS is a monster and most unlikely to ever be running on a desktop Amiga. It's for high-end servers.

I wasn't thinking of the entire ZFS implementation, more just the pool parts with a device into the pool and some means of each "volume" having all of it's parts pooled together.

As MTB support would be too much, then it would need to be another mechanism then.

I'be been looking at mirroring volumes across multiple HDDs on my sam440.

As it would be filesystem specific, then date stamps would order parts and the filesystem would have to internally handle everything itself.

So you are looking first at a new file system designed with support for software RAID?

Interesting idea.

Or more specifically looking at some way where multiple partitions with a common name can be sequenced together as a single larger volume, separate "partition" dosdrivers merged as a single volume.

Something equivalent to the deviceio.library for dealing with mirror and append block read/write access.
The list of DOS device nodes for the single volume becoming equal to a "zpool" for a single volume.

I'be worked out some ideas towards making something like zeta filesystem but as you already pointed out, not all of it is needed.

I'm more looking to cherry pick features and see how they might fit into AmigaOS at this time.

Partially because of target needs in Polymorph-VMM and I want to avoid needing anything to "shutdown" without being majorly brain damaged when power loss occurs.

I'm also getting sick to death of leaving my machine to finish tasks and "helpful" individuals switching it off before completion of automated tasks after I go away.

I also see no point in making the equivalent to a full device driver or filesystem stack for a target in Polymorph-VMM without benefits to the host OS for the needed functionality.