have you, or any of the testers, tried this on a brand new unused physical system and if so what are the problems?
I haven't actually done it with a "new" system. I did put a spare 500 GB disk into both my Lenovo ThinkPads (T510, and L530), and restored them to "factory" status. Then, I installed ArcaOS. The main "problem" is to get the partition sizes reduced to make room for ArcaOS, AND, to make LVM happy. Shrinking the main windows C: is easy enough, but the recovery partitions (may) extend past the last full cylinder, so you also need to shrink the recovery partition. The tool that is supplied needs a button, to shrink it by the smallest possible amount, but all it has is a large slider, and it is difficult to do a small amount (which you cannot expand again, if you take too much). I recommend that you use the tool, booted from the ArcaOS installation DVD, so that there is no chance that it will use the wrong partitioning scheme. I used a 500 GB disk, so there was no problem with the geometry. Larger disks may need to be wiped clean, partitioned by the ArcaOS tools, then restore whatever was there before. You MUST use a proper backup program. If it simply restores the whole partition image, it will likely end up exactly the way that it started. The ONLY windows program, that I know of, that will do it properly, is Acronis. That includes the reduced function Acronis, known as Seagate Disk Wizard, but you need a Seagate, Maxtor, or Samsung, disk to be able to use it (the disk can be in an external USB enclosure).
Yep, HPFS would then be the FS of choice. Question is, would that missing caching be a problem on a RAM drive? RAM is quick, so why cache anything at all? (And wouldn't caching slow down the I/O on a ram drive?)
Actually, the cache is a bit of a problem, because it is not missing. The cache is extra overhead, and slows the disk down. HPFS cache cannot be reduced to less than 64 MB. If you use the file system with real disks, you need to use a larger cache for them, or lose performance, but it is still used with the RAMDISK, because there is no way to isolate them from the rest. JFS has the same problem. I have been using HPFS for the RAMDISK, and JFS for the rest. All I have tried, so far, is reducing the HPFS cache to 64 MB. Some other settings may also reduce the cache usage. In fact, the fastest is FAT16, but that is limited to 2 GB. FAT32 is slow, like all other implementations of FAT32. HPFS works pretty well, and it is much faster than any real disk (a fast SSD may keep up). Of course, there are a lot of things that can affect the speed.
On Linux and Windows I found out, that VirtualBox is slowing down I/O for large files, but small ones are accessed, written, read extremely fast. Appears to be a VirtualBox internal problem.
I've ran benchmarks inside and outside of VBoxes in both Linux and Windows for ram drives. Outside of a VM the performance was (of course) god like, even on huge files. Inside of such a box however, I never could cross the 90 MB/s on huge files' transfer from and to the same virtual hard drive. Other story for small files. Even inside the box, these use to be uber fast, as expected of a ram drive stored virtual drive. ( : - So the benefit of running an OS on a ram drive stored VM is still great imo, compared to benchmarks when the VM is stored on a (Raptor) physical HDD.
In VBOX, under windows, you have the option to use the host system disk cache, and you can mark the guest drives as being SSD. You can also use AHCI, which speeds it up. Some, or all of that makes a lot of difference to virtual disk performance. I would guess that VBOX under any version of OS/2, will never perform well enough to be using it that way, but I don't know a lot about that project. What would be really good, would be if they could use the memory above what OS/2 can normally use. The RAMDISK memory support actually opens that window, but a lot of work is required to flesh it out so it can be used.
Ahh I see. 1 GB for the operating system and 2,x GB for the guests is quite small indeed
It depends on the guest OS. If it will run with a small memory, you can use more guests. Fine tuning that stuff is probably more of an art, than a science, and what works with VBOX under windows, may not work under *NIX. AFAIK VBOX under OS/2 is currently limited to one guest (but that is supposed to be fixed).
Currently, I would suggest that OS/2 works much better as a guest, than as a host, for virtual machines.