Author Topic: RAM disk and temp folders...what else?  (Read 41963 times)

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
Re: RAM disk and temp folders...what else?
« Reply #30 on: April 18, 2018, 02:25:39 pm »
You would think you are correct in that thinking. I would not use HPFS386 on a ramdisk if I had a choice, but it is a HPFS or HPFS386 type of a decision, so I have no choice in this matter, I am forced to run HPFS386 only. Since HPFS386 allows you to shut the cache off for the ramdisk created by QSINIT itself, as best as I can tell this should not a problem.

..and yet the numbers I see tell an entirely different story...

I am basing this last conclusion on the output I see from 'cache386 /o' command and throughput numbers I see from 'Lars Commander' during a file copy operation. If I then compare the speed throughput for the ramdisk with the cache ON and OFF I see the following:

1) HPFS386 cache ON - 600 Meg file copy from HD to ramdisk
Peak => 108,586K
Avg => 104,278K
Last => 108,420K

2) HPFS386 cache OFF
Peak => 53,079K
Avg => 26,325K
Last => 27,736K


You leave it completely unclear if "cache386 /o" turns off the cache for ALL HPFS386 formatted partitions or only for the Ramdisk. Then you leave it completely unclear if you were copying from/to a HPFS386 formatted partition to/from a HPFS386 formatted partition or to/from a partition unaffected by the cache setting.
I have the impression that both source and target partitions were HPFS386 partitions ...

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1317
  • Karma: +26/-0
    • View Profile
Re: RAM disk and temp folders...what else?
« Reply #31 on: April 18, 2018, 05:25:45 pm »
Hi Lars!

Umm...sorry...I completely do not get what led you to make the below statements, but allow me to re-iterate what I previously stated in my response to your post.

Originally you stated the following:

Why would you use HPFS386 on a ramdisk anyway ?

I then answered by providing the empirical evidence as per my tests:

You would think you are correct in that thinking. I would not use HPFS386 on a ramdisk if I had a choice, but it is a HPFS or HPFS386 type of a decision, so I have no choice in this matter, I am forced to run HPFS386 only. Since HPFS386 allows you to shut the cache off for the ramdisk created by QSINIT itself, as best as I can tell this should not a problem.

..and yet the numbers I see tell an entirely different story...

I am basing this last conclusion on the output I see from 'cache386 /o' command and throughput numbers I see from 'Lars Commander' during a file copy operation. If I then compare the speed throughput for the ramdisk with the cache ON and OFF I see the following:

1) HPFS386 cache ON - 600 Meg file copy from HD to ramdisk
Peak => 108,586K
Avg => 104,278K
Last => 108,420K

2) HPFS386 cache OFF
Peak => 53,079K
Avg => 26,325K
Last => 27,736K

...and that led you to conclude the following (which is what I do not understand at all):

You leave it completely unclear if "cache386 /o" turns off the cache for ALL HPFS386 formatted partitions or only for the Ramdisk. Then you leave it completely unclear if you were copying from/to a HPFS386 formatted partition to/from a HPFS386 formatted partition or to/from a partition unaffected by the cache setting.
I have the impression that both source and target partitions were HPFS386 partitions ...

So I thought it was pretty clear that in the context of the thread we were talking about the suitability of turning on the HPFS386 cache for a ramdisk, I mean after all, your original post response (which I quoted above for ease of reference) specifically stated so, or where you simply questioning whether one would want to use HPFS385 filesystem as opposed to something like FAT, FAT32 or JFS???

Alright, so let me confirm: YES, the HPFS386 cache is being turned ON for ramdisk and I am attempting to assess the impact on ramdisk performance with the HPFS386 cache being in either ON or OFF setting.

Further on, my reference to 'cache386 /o', given the context of the conversation, specifically relates to what cache386 output provides as applicable to the ramdisk, such as:

Code: [Select]
[G:\]cache386 /o
CACHE386 options
Cache Size    65536 KB

Drive F:
   Lazy write:             OFF

Drive G:
   Lazy write:              ON   MaxAge:          15000 msec
                                 BufferIdle:       5000 msec

In the above example this shows that HPFS386 cache is active for the G: drive (which is my boot drive), and it is not active for F: drive, which is my maintenance partition.

Therefore:

You leave it completely unclear if "cache386 /o" turns off the cache for ALL HPFS386 formatted partitions or only for the Ramdisk...

...as explained above, the 'cache386 /o' is applicable to the status of the HPFS386 cache for ramdisk only.

Further on:

...Then you leave it completely unclear if you were copying from/to a HPFS386 formatted partition to/from a HPFS386 formatted partition or to/from a partition unaffected by the cache setting...

...which is not the case since I specifically stated the following:

...
1) HPFS386 cache ON - 600 Meg file copy from HD to ramdisk
...

Given that I am looking to answer the 'should I turn ON the HPFS386 cache for ramdisk' question only, I would not be shutting OFF my physical HD HPFS386 cache, it simply would not make sense to do so since when the machine is in production mode it would never run without the HPFS386 cache being turned ON.

OK, I hope that clarified whatever may have been causing confusion.

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
Re: RAM disk and temp folders...what else?
« Reply #32 on: April 18, 2018, 06:36:49 pm »
A lot of words that makes it yet more complicated. So my questions are:
1) do you ONLY have HPFS386 partitions on your HD ? Or do you also have JFS partitions ?
2) have you been copying from G: to ramdisk ?
3) What driveletter does your ramdisk have ? It seems that it is neither F: nor G: so what is it ?
4) What is the switch to cache386 to explicitely turn on/off caching for a specific drive letter ?

Ben

  • Guest
Re: RAM disk and temp folders...what else?
« Reply #33 on: April 19, 2018, 12:52:26 am »
I am trying to get the HPFS386.IFS driver loaded, to get the QSINIT Ramdisk to work, but for some reason I get the following error:

"The file Y:\IBM386FS\HPFS386.IFS specified in the IFS statement on line 26 of the config.sys file does not contain a valid device driver or file system driver. Line 26 is ignored"

My config.sys entry is a simple one; "IFS=Y:\IMB386FS\HPFS386.IFS /A:R" where "Y:" is the boot drive and "R" is the RAMDisk.

I am using the default settings for HPFS386.INI and I put HPFS386.DLL in the OS2\DLL folder, (should it be needed)... does it require a config.sys entry? There is nothing in the instructions saying that it does.

Have I overlooded something obvious?

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4788
  • Karma: +99/-1
    • View Profile
Re: RAM disk and temp folders...what else?
« Reply #34 on: April 19, 2018, 02:04:10 am »
Why not just use the regular HPFS driver?

Ben

  • Guest
Re: RAM disk and temp folders...what else?
« Reply #35 on: April 19, 2018, 03:02:33 am »
I may end up with no choice.

HPFS386 should work though maybe it doesn't work on newer software.

The RAMDisk is working fine otherwise as far as I can test it.

Pete

  • Hero Member
  • *****
  • Posts: 1281
  • Karma: +9/-0
    • View Profile
Re: RAM disk and temp folders...what else?
« Reply #36 on: April 19, 2018, 03:46:20 am »
Hi Ben

My config.sys entry is a simple one; "IFS=Y:\IMB386FS\HPFS386.IFS /A:R" where "Y:" is the boot drive and "R" is the RAMDisk.



Is the "Y:\IMB386FS\" above a copy'n'paste typo?


Regards

Pete

Valery Sedletski

  • Sr. Member
  • ****
  • Posts: 368
  • Karma: +2/-0
    • View Profile
Re: RAM disk and temp folders...what else?
« Reply #37 on: April 19, 2018, 06:07:27 am »
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?
« Last Edit: April 19, 2018, 07:04:05 am by Valery Sedletski »

Lars

  • Hero Member
  • *****
  • Posts: 1271
  • Karma: +65/-0
    • View Profile
Re: RAM disk and temp folders...what else?
« Reply #38 on: April 19, 2018, 03:29:28 pm »
You already gave the answer why nobody uses emsFS.IFS:

1) I did not even know such a thing existed. I don't know where to get it. I am sure that others have the same problem.
2) it requires using the OS4 kernel. Unfortunately that kernel does not properly work on my system and tends to freeze my system.
For the VAC 3.0 profiler I have made a fix (a replacement for CPPOPA3.OBJ) to work around a bug in DOSCALL1.DLL so that the profiler finally works (at least with windowed applications). That works with the eCS and AN kernels but it fails with the OS4 kernel.


What I often lack for the OS4 project is some information page that tells me what stuff exists, how it works, what the restrictions are and where to get them. For example OS4APIC.PSD is largely undocumented and I only found it by chance on the OS4 web page. It allowed me to use multicore CPU but since it is not an ACPI implementation I don't know what the implications are.
There are a bunch of other drivers like CLOCK03.SYS etc. where it's also not clear if these drivers are mandatory or not and if they have to be added to config.sys or if they are loaded automatically by the kernel.

ivan

  • Hero Member
  • *****
  • Posts: 1558
  • Karma: +17/-0
    • View Profile
Re: RAM disk and temp folders...what else?
« Reply #39 on: April 19, 2018, 05:57:58 pm »
Hi Lars,

I couldn't agree more with your statement.

I would like to try the OS4 kernel and other programs and drivers but there is nowhere enough information to let me do so - I have been told that it allows the AMD Ryzen processor to work, something I would very much like to happen.

Valery Sedletski

  • Sr. Member
  • ****
  • Posts: 368
  • Karma: +2/-0
    • View Profile
Re: RAM disk and temp folders...what else?
« Reply #40 on: April 19, 2018, 05:59:12 pm »
2Lars: Where to get??? On Hobbes. If the kernel is not properly work on your system, you should report that to the developers, so that they will fix it. But you don't want. So, who is guilty?

All available stuff is either on Hobbes, or at official webpage, http://gus.biysk.ru/os4/. All, who needs it, knows about it. os4apic.psd is documented in kernel readme's. At least, available command line switches. What else is needed? It is not ACPI implementation, because ACPI is separate from PSD. ACPI is available for interested testers (including me). It is a special kind of driver (a PDD, but it is loaded before PSD, and it communicates to PSD, so that PSD gets ACPI tables info from it. Alternatively, IRQ routing info can be get from MPTable). Drivers like CLOCK03c.SYS are mandatory, but they are loaded by kernel without the need to be written into CONFIG.SYS (the same way as CLOCK01.SYS. CLOCK03c.SYS is loaded instead of CLOCK01.SYS, and contains both CLOCK and TIMER drivers. Plus, it contains support for hi-res timer, based on HPET). The same for SCREEN03.SYS. There are also OEMHLP.BPD and ACPI4.BPD, which contain OEMHLP$ and ACPICA$ implementations. All these should be not written into CONFIG.SYS. Everything should be described in readme's, otherwise you can ask developers. They are responsive.

Ben

  • Guest
Re: RAM disk and temp folders...what else?
« Reply #41 on: April 19, 2018, 08:00:27 pm »
Hi Ben

My config.sys entry is a simple one; "IFS=Y:\IMB386FS\HPFS386.IFS /A:R" where "Y:" is the boot drive and "R" is the RAMDisk.



Is the "Y:\IMB386FS\" above a copy'n'paste typo?

Typo unfortunately.

I tried it on two different installations on two different machines with the same error.

I vaguely recall from the distant past, that HPFS386.IFS wouldn't load without some sort of memory restrictions... virtualmemorylimit adjustment or something like that. But I have that setting tweaked for other programs and I have no intention of changing it..

I take it that file system drivers, (*.IFS), can be loaded from anywhere not  just from config.sys path statements in the libpath, path dpath?

I guess that I have no choice but to use the basic HPFS.

Andi B.

  • Hero Member
  • *****
  • Posts: 812
  • Karma: +11/-2
    • View Profile
Re: RAM disk ... offtopic HPFS386
« Reply #42 on: April 19, 2018, 08:16:12 pm »
I've in config.sys

IFS=m:\IBM386FS\HPFS386.IFS /A:*
CALL=m:\OS2\CMD.EXE /Q /C m:\IBM386FS\CACHE386.EXE

And a few notes like -
"REM ! EARLYMEMINIT=TRUE   unreming may be needed for JFS chkdsk on large volumes but does not work with HPFS386"
"REM ! HPFS386 does not work anymore with VIRTUALADDRESSLIMIT=2048 - too less memory, going back to VA = 1536"




Ben

  • Guest
Re: RAM disk and temp folders...what else?
« Reply #43 on: April 19, 2018, 08:37:43 pm »
Interesting, Andyy

With that in mind, I won't bother with HPFS386.
While it appears to have some performance increases over HPFS it's not worth the hassel for a RAM disk.

I'll add your comments to my CONFIG.SYS.

Thanks for that heads-up.

OS4User

  • Sr. Member
  • ****
  • Posts: 406
  • Karma: +10/-0
    • View Profile
Re: RAM disk and temp folders...what else?
« Reply #44 on: April 19, 2018, 10:05:23 pm »
There are a bunch of other drivers like CLOCK03.SYS etc. where it's also not clear if these drivers are mandatory or not and if they have to be added to config.sys or if they are loaded automatically by the kernel.

I would like to try the OS4 kernel and other programs and drivers but there is nowhere enough information to let me do so.

Lars, Ivan

OS/4 distr contains HowTo file about installation process of OS/4 kernel.
Pls let me know if anything is unclear in this file and still creates complication.

If any technical questions arise, pls put them into https://www.os2world.com/forum/index.php?topic=1735

Ivan, at least two persons reported about successful run OS/4 on Rysen https://www.os2world.com/wiki/index.php/Phoenix_OS/4#OS.2F4_Tested_Hardware_List