2Lars:
> As to STRAT1 method: as far as I can remember from the OpenJFS code I think JFS.IFS will fall back to the STRAT1 method when it cannot find a STRAT3 (flat addressing) entry point. Of course that is irrelevant nowadays as the 32-bit (most recent) OS2DASD.DMD supports the STRAT3 entry point. But the old 16-bit version of OS2DASD.DMD did not.
On the other hand, I think that JFS.IFS will only work with the new OS2DASD.DMD + OS2LVM.DMD.
(Open)JFS will fall back to strat2, not strat1, if strat3 is not supported. JFS does not support strat1 (as well as HPFS386 does not). JFS.IFS works fine with 16-bit OS2DASD.DMD form Merlin/Warp3 (and DANIDASD.DMD), because it falls back to Strat2, I think.
Also, this is not irrelevant now, as 16-bit OS2DASD/DANIDASD can still be used on the modern system. I use DANIDASD in my universal bootable OS/2 stick, for example.
> Also: VFDISK.SYS (the virtual floppy disk driver, a legacy block device driver) only supports the STRAT1 entry point. But given the fact that you can only format virtual floppies to FAT anyways that should not be a problem.
BTW, using SVDisk.sys, you can easily format virtual floppy as HPFS (with SVDisk own HPFS format tool), then you can take a floppy image with savedskf.exe, and restore it to a physical floppy, or VFDISK.SYS virtual floppy, using loaddskf.exe. Also, I was able to format floppies with Macintosh HFS file system, and use them with HFS.IFS on OS/2. (HFS hybrid CD's work fine too, BTW).
2Dariusz Piatkowski:
> Yup, similar configuration to what I currently have. My operating partitions are all HPFS386, the nightly backup partitions are HPFS386 as well but no CACHE on them. Neither is the RAMDISK, else it defeats the purpse.
You still use HPFS386 as your main file system? Why not JFS? HPFS386 has limitation of 64 GB max partition size, like ordinary HPFS driver. So, how do you use it with modern hard disks?
I moved to JFS 17 years ago, since my partitions are all bigger than 64 GB.
2all: BTW, why nobody here is mentioned emsFS.IFS ramdisk? It uses memory above 4 GB too, but uses PSE36, instead of PAE for accessing this memory. It maps a 4 MB pages above 4 GB limit to a 4 MB window below the 4 GB limit, without switching PAE on/off and copying data. PSE36 is enabled permanently, and no copying is done, only mapping. Also, emsFS.IFS is based on ramfs.ifs. So, it has all the benefits of ramfs.ifs, like absence of block layer. So, it is IFS-based, hence no block layer and caching overhead. So, according to my tests, it is about 5 times faster than PAE ramdisk from QSINIT.
The disadvantages of emsFS.ifs is that it requires the OS/4 kernel as it uses special KEE's for PSE36 access. Also, there is no support for restoring the disk contents like QSINIT does with its "unzip" command. On the other hand, QSINIT is significantly slower.
Also, QSINIT advantage is that it unzip's files at the early stage, and then you can boot from this ramdisk, like with Veit's Memdisk. So, you can create bootable flash sticks.
But you can create bootable flash stcks and boot from emsFS/RAMFS too, if using my FreeLDR boot loader, together with bootos2.mdl OS/2 booter. This is done in my universal OS/2 boot disk (which can boot from flash/CD/harddisk media).
So, did anybody tried emsFS.IFS here?