Subj : Re: How to detect RAM disks (Was: how to detect cdrom?) To : Steve From : Matthias Paul Date : Thu Feb 14 2002 08:25 pm From: Matthias.Paul@f3.n342.z1.cereal.mv.com (Matthias Paul) Subject: Re: How to detect RAM disks (Was: how to detect cdrom?) From: "Matthias Paul" On 2002-02-14, Steve Fabian wrote: > 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. Well, Steve, what you refer to are drives which are hooked into the system via the network redirector, sometimes also known as IFS API; these are of course "virtual disks" (at least from the viewpoint of the client OS), but not what most people mean when speaking of "virtual disks" under DOS. So far I have never seen a DOS RAM disk driver of any origin using the redirector interface, all (but one) have been block device drivers (and therefore used some form of FAT), which hook into the system at a much deeper level, and one particular driver hooked into the system down at INT 13h level. > Only if the driver relies on the FAT drivers built into the BDOS > part of the OS does it need to look like FAT; even then it could > be FAT32/VFAT. Yes. > I don't see a technical reason why a virtual disk must have a > single FAT. Not must, but all RAM disk drivers I know of at least /use/ FAT. Using FAT you can significantly reduce the resident footprint of the driver, as you do not have to implement the file-system stuff. While RAMDRIVE.SYS and VDISK.SYS still take a few Kb, coding a full file-system would not be possible to do in less than 5 - 10 Kb, complex file-systems like HPFS, NTFS, or ext2fs would require much more. Some fully functional but extremely optimized low-footprint FAT RAM disk drivers like TDSK (or BITDISK) can live in just 608 (or 256) bytes precious DOS memory, this is possible because all the resident driver has to do is translate logical sectors into the corresponding memory addresses and move the data back and forth. In regard to one FAT versus two (or more) FATs, I think the main reason to use only one FAT for RAM disks is a historical one: The oldest RAM disk drivers had to live in conventional memory, and using only one instead of two FATs you could save some memory in the drive image, and therefore DOS memory. This is also the reason, why RAM disks usually default to 128 byte sectors; the smaller the sector overhang, the more files could be stored in as little memory as possible. (There's an optimimum and this does not hold true for all average file sizes.) > I think that a better test would be to ensure that the drive > is not cached, Good idea - putting the actual burden to properly detect a RAM disk on the implementation of a disk cache... ;-) But then, how do you want to test if a drive is actually cached? You could query some disk cache's APIs, but you would always miss some others... Also, most disk caches use similar methods (disk label, OEM label, one FAT, INT 13h access) to test for RAM disks themselves, I have yet to see a disk cache which's RAM disk test could not be fooled by setting up a RAM disk with some special values, unfortunately. So, this will not be much more reliable in practise. > 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). Yes, this is also a good idea, but very difficult to do in practise, not only because of the large differences in speed between the machines from the earliest 4.77 Mhz PC to todays 2 Ghz number crunchers, but also those in the RAM disks themselves. Different memory areas may significantly differ in access speed, in particular on older machines, or when EMM386 or similar is involved, or when using conventional, UMB, or EMS memory. Another problem is that it is very difficult to do accurate high resolutions timings in the PC architecture, and in the few cases, where the hardware offers special high-res timers, it is at least very hardware- dependent and invasive... Well, a heuristical combination of all these tests might give a very good indication of a RAM disk... Greetings, Matthias -- ; http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org -- |Fidonet: Matthias Paul 1:342/3 | | 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) .