AOS disk size limitation?

[Doug Clark]

Is the AOS RAM disk bound by the same file system limitations as "normal" disks?

Meaning - is an AOS HPFS formatted to HPFS limited to 2GB - as is normal for HPFS?  Or does the RAM do something "special" that allows it to transcend regular file system limitations?

Without thinking about this I set the RAM disk up to use 8gb of high memory format as HPFS and have been booting that way for months.  I don't think I have ever copied more than 2 GBs to the RAM drive - but what would happen if I did?

The help says is "The AOS loader can format the drive(s) it creates using FAT, FAT32, or HPFS; it can also leave them unformatted. Both drives will be formatted the same way. Note that if you choose FAT, any drive over 2gb will be left unformatted."

Since JFS is not an option on the RAM disk setup dialog I switched to FAT32 - but that makes the drive VERY SLOW.

I also tried reformatting the drive as JFS using the WPS drive object but the application I was running using files on the RAM disk (VLC) started behaving very strangely.

I seem to remember having to put IFS=HPFS

[Dave Yeo]

The limit for OS/2 HPFS is 64GB, in practice somewhat less, perhaps 60GB for stability, so a 8GB ram disk is no problem. The 2GB limit is the file size limitation on HPFS.
If you want JFS, add this to startup.cmd (ram disk is H: here, adjust as needed)

Code: [Select]

if exist H:\jfs.part goto next
FORMAT.COM H: /FS:JFS <REPLY_Y.txt
sleep 1
touch h:\jfs.part
:next
And create reply_y.txt besides startup.cmd in the root of your boot volume containing Y
This will preserve the JFS volume across reboots if you've set the ram disk to preserve its contents and your hardware allows it.

[Doug Clark]

Thanks Dave for the info.

Sorry I posted this twice - I thought the first post had disappeared and so I re-posted.

What drove me to JFS from HPFS was the difference in CHKDSK times.  CHKDSK on HPFS takes forever on large volumes.   Since a RAM disk  gets thrown away on reboot CHKDSK is a non-issue.  And the "thrown away on reboot" is, for me, one of the advantages of a RAM disk.   Fits right in with my lazy, never get around to it,  disk  housekeeping tendencies.

[Doug Clark]

Thanks Dave - the format routine is clever.

[Dave Yeo]

Doug Bisset came up with the format routine, I expanded it to keep the JFS volume there between warm reboots.
I often use the ramdisk as a scratch work area, so like it to be preserved for a warm reboot, which includes the system dump keys (CTRL-ALT-F10 twice) when the OS locks up, which does mean running chkdsk on the ram disk.
Eventually there's a cold reboot to clean the ram disk and even with only a 4GB ram disk, I haven't had it fill up.

[Andy Willis]

Code: [Select]

if exist H:\jfs.part goto next
FORMAT.COM H: /FS:JFS <REPLY_Y.txt
sleep 1
touch h:\jfs.part
:next
And create reply_y.txt besides startup.cmd in the root of your boot volume containing Y
This will preserve the JFS volume across reboots if you've set the ram disk to preserve its contents and your hardware allows it.

I added:
if not exist q:\file.file chkdsk q: /f:2
before the format, that way I could preserve the JFS volume in case of a crash and only takes only a second if it is a fresh boot.

[Dave Yeo]

Code: [Select]

if exist H:\jfs.part goto next
FORMAT.COM H: /FS:JFS <REPLY_Y.txt
sleep 1
touch h:\jfs.part
:next
And create reply_y.txt besides startup.cmd in the root of your boot volume containing Y
This will preserve the JFS volume across reboots if you've set the ram disk to preserve its contents and your hardware allows it.

I added:
if not exist q:\file.file chkdsk q: /f:2
before the format, that way I could preserve the JFS volume in case of a crash and only takes only a second if it is a fresh boot.

Shouldn't be needed if you have /AUTOCHECK:* on your JFS.IFS line in config.sys, same with HPFS.
You can test, close everything and without the chkdsk command in startup folder, initiate a trap dump and see if the volume gets chkdsked during boot, even faster as it usually just does logredo. If too quick, see if the volume is clean.
Couple of computers back I had one that immediately rebooted if you turned it off and back on. The ram disk would survive a couple of seconds of no power, a second more and chkdsk would run and usually the contents were still there, not that I trusted it at that point. This was HPFS back then.

[Andy Willis]

Code: [Select]

if exist H:\jfs.part goto next
FORMAT.COM H: /FS:JFS <REPLY_Y.txt
sleep 1
touch h:\jfs.part
:next
And create reply_y.txt besides startup.cmd in the root of your boot volume containing Y
This will preserve the JFS volume across reboots if you've set the ram disk to preserve its contents and your hardware allows it.

I added:
if not exist q:\file.file chkdsk q: /f:2
before the format, that way I could preserve the JFS volume in case of a crash and only takes only a second if it is a fresh boot.

Shouldn't be needed if you have /AUTOCHECK:* on your JFS.IFS line in config.sys, same with HPFS.
You can test, close everything and without the chkdsk command in startup folder, initiate a trap dump and see if the volume gets chkdsked during boot, even faster as it usually just does logredo. If too quick, see if the volume is clean.
Couple of computers back I had one that immediately rebooted if you turned it off and back on. The ram disk would survive a couple of seconds of no power, a second more and chkdsk would run and usually the contents were still there, not that I trusted it at that point. This was HPFS back then.

I kept having it not be available due to needing a chkdsk.

[Dave Yeo]

I kept having it not be available due to needing a chkdsk.

That's strange, had to force a reboot yesterday, watched during boot that chkdsk ran on the ram disk.

[Doug Clark]

On the other thread (sorry again) there were some comments on the speed of the RAM disk.

So I thought I would post some times.  The first set is transfer speeds across a network - not really RAM disk related but establishes a baseline.  It appears the wirespeed is the limiting factor rather than source or destination disk types.

The second set is transfer times from disk to disk on the same machine: M.2 to spinning disk, M.2 to RAM disk, RAM disk to RAM disk.
I did not do any M.2 to M.2, or any RAM to M.2  - cause the file was 2GB in size and I didn't want to waste any more writes on the NVMe than I already had.

Across a 1gb wired network - Netbios
====================================
Source Machine
WSeB on eComStation
AMD AM3+ socket FX4350 processor
3G/bs SATA
Intel NIC/Intel driver

Destination Machine
AOS v 5.1
Ryzen 5 5600X processor
PCIe gen 4 M.2 MVNe
6Gb/s SATA
Intel NIC/Intel driver

900MB file size

All times from Larsen Cmdr  Avg bytes per second for the transfer


SATA network to RAM
-------------------
25,055k

SATA network to Spinning
-------------------------
25,456k

Spinning network to Spinning
-----------------------------
25,319K


On Destination Machine - Drive to Drive
=======================================

2GB file size

Spinning to Spinning
--------------------
36,441K

Spinning to M.2
---------------------
139,586K

M.2 to RAM Disk
---------------
512,500K
493,447K
654,337K
381,786K
388,793K


RAM to RAM
------------------
396,887K
155,725K
219,919K
192,912K

Spinning to RAM
---------------
172,038K
172,661K
176,944K

[Dave Yeo]

You seem to get better numbers then me.
AOS ISO, about 90,000k bps from M2 to ram, 48,000k bps from ram to M2.
Ram to ram, about 29k
From M2 to SATA SDD, almost 500M bps, from SATA to M2, almost 400M bps.
This using FC/2, the M2 is GPT, so overhead of the filter, whereas the SATA SDD is regular MBR.
7th Generation I5, last computer was quite a bit slower to ram and I'd assume a newer one would be faster. Still I find the ram disk fast enough.