Subj : Re: How to detect RAM disks (Was: how to detect cdrom?)
To   : Matthias Paul
From : Jasen Betts
Date : Sun Feb 17 2002 08:04 am

From: Jasen.Betts@p42.f531.n640.z3.cereal.mv.com (Jasen Betts)
Subject: Re: How to detect RAM disks (Was: how to detect cdrom?)

Hi Matthias.

14-Feb-02 20:25:56, Matthias Paul wrote to Steve

 >> Since a virtual disk is essentially an installable file system, it
 >> could be HPFS in a Win98 or NTFS in an OS/2 platform, or Linux
 >> under either vendor, as long as the relevant drivers are included.

 MP> Well, Steve, what you refer to are drives which are hooked into
 MP> the system via the network redirector, sometimes also known as IFS
 MP> API; these are of course "virtual disks" (at least from the
 MP> viewpoint of the client OS), but not what most people mean when
 MP> speaking of "virtual disks" under DOS. So far I have never seen a
 MP> DOS RAM disk driver of any origin using the redirector interface,

Neither have I, unles you count a linux ramdisk mounted via the redirector
in a dosemu session. (you could also pass the ramdrive to dosemu as an image
where it would appear as a phisical (int-13) disk)

 MP> all (but one) have been block device drivers (and therefore used
 MP> some form of FAT), which hook into the system at a much deeper
 MP> level, and one particular driver hooked into the system down at
 MP> INT 13h level

I saw one like that in PCDOS 2.2

 MP> [...] but all RAM disk drivers I know of at least /use/ FAT.
 MP> Using FAT you can significantly reduce the resident footprint of
 MP> the driver, as you do not have to implement the file-system stuff.

But you lose out on all the unused space,  with a virtual filesystem you
could allocate ram from the xms pool as it is required and deallocate it as
files are deleted... (the Amiga ramdisk worked in this way, I haven't seen
one like it for dos)

 MP> While RAMDRIVE.SYS and VDISK.SYS still take a few Kb, coding a
 MP> full file-system would not be possible to do in less than 5 - 10
 MP> Kb,

yeah.

 >> and measure the drive access time to the first and last cluster. If
 >> the times are the same and are in the submillisecond range,
 >> comparable to access times of blocks of internal storage, one could
 >> reasonably assume that it is a virtual disk, implemented in
 >> internal storage (RAM).

 MP> Yes, this is also a good idea, but very difficult to do in
 MP> practise, not only because of the large differences in speed
 MP> between the machines from the earliest 4.77 Mhz PC to todays 2 Ghz
 MP> number crunchers, but also those in the RAM disks themselves.
 MP> Different memory areas may significantly differ in access speed,
 MP> in particular on older machines, or when EMM386 or similar is
 MP> involved, or when using conventional, UMB, or EMS memory. Another
 MP> problem is that it is very difficult to do accurate high
 MP> resolutions timings in the PC architecture,

The timer chip contains a timer counter that runs at over 1 MHZ this can be
probled quite easily... (I have source here)

 MP> and in the few cases,
 MP> where the hardware offers special high-res timers, it is at least
 MP> very hardware- dependent and invasive..

true it's invasive, (needs hardware access) and somewhat hardware
dependant (I've noted that two methods to probe the timer and it
depends on hardware as to which one will work reliably)

 MP> Well, a heuristical combination of all these tests might give a
 MP> very good indication of a RAM disk..

yeah...

 -=> Bye <=-
--
|Fidonet:  Jasen Betts 3:640/531.42
|
| Origin: The Cereal Port BBS (603)899-3335 199.125.78.133 (1:132/152)


---
 # Origin:  (1:132/152.4)
 * Origin: Baddog BBS (1:218/903)

.