seifert@sun1.ruf.uni-freiburg.de (Ulrich Seifert) (09/06/90)
In the near future I am going to upgrade my system to OS/2 vs. 1.2 and
I will also get a new hard disk. While shopping around I saw the DPT
SmartCache controllers. I don't know if I want to buy it but it raised a
quite general question which I would like to post here.
Within HPFS there is already the possibility to configure a cache system.
Does anybody know how it works exactly? Is it a kind of cache that just
looks if it has the requested sector in memory or does it also some read-
look-ahead or a kind of ordered write back to disk...?
Let us assume we put a cache controller into the system. This may do all
those things like buffering the most frequently used sectors, read-look-ahead
of a few sectors, and optimized write back to disk (I believe these are the
main features of the DPT). Does it help anything?
Is somebody running a system with a cache controller who could give us an
idea if works faster/just the same/even worse?
I hope that this question hasn't been addressed in a magazine or so. In this
case I have to apologize but unfortunately I have only access to very few
U.S. magazines (which sometimes makes you feel like living on the back of the
moon).
Thanks,
Ulfgregj@microsoft.UUCP (Greg JONES) (09/14/90)
In article <1990Sep6.141036.11041@sun1.ruf.uni-freiburg.de>, seifert@sun1.ruf.uni-freiburg.de (Ulrich Seifert) writes: > Within HPFS there is already the possibility to configure a cache system. > Does anybody know how it works exactly? Is it a kind of cache that just > looks if it has the requested sector in memory or does it also some read- > look-ahead or a kind of ordered write back to disk...? > Let us assume we put a cache controller into the system. This may do all > those things like buffering the most frequently used sectors, read-look-ahead > of a few sectors, and optimized write back to disk (I believe these are the > main features of the DPT). Does it help anything? > HPFS caching cannot be totally disabled, it can only be shrunk. Almost all disk I/O done by HPFS (and certainly all I/O for control sectors like directories and so on) goes through its cache. The disk format is optimized to make the best use of how this cache operates. HPFS will cache frequently used sectors on an LRU basis; this gets modified according to the relative likelihood that the sector will be needed again. For example, a directory block is likely to be very popular, but the FNODE for a file that's being deleted probably won't be. HPFS also does some read-ahead of file data and background lazywriting. In general it's better to let the filesystem do the caching, since it knows what kind of information is best to cache. uunet!microsof!gregj [I just happen to work here. Sheer coincidence.]
gordonl@microsoft.UUCP (Gordon LETWIN) (09/14/90)
In article <1990Sep6.141036.11041@sun1.ruf.uni-freiburg.de>, seifert@sun1.ruf.uni-freiburg.de (Ulrich Seifert) writes: > > Within HPFS there is already the possibility to configure a cache system. > Does anybody know how it works exactly? HPFS always has a cache; you get to decide how big to make it. The "standard" HPFS, released with OS/2 1.2, allows up to 2 megs of cache. The cache is designed so that you can run with a 2 meg cache without bottlenecking in the buffer search code - the search is very fast even for large caches. This HPFS can be configured to do write behinds; I think that may be the default. This delays writes until the disk goes idle for a couple of seconds or until the data gets too old (risky to leave unwritten for too long a period of time) or until the cache gets too dirty. The performance effect of this is threefold: 1) writes take place faster. For a program that does burst I/O, the writes can be "free" because they're slipped out during the otherwise idle disk periods. 2) redundant writes are collapsed together - such as when you create or close several files and the directory needs to be written to update each dirent. The delay process will fold these multiple writes into one. 3) better head organization. Even for a large copy *.* operation the heads will tend to sit on the "from" spot longer then move to the "to" spot longer. This effect isn't so strong for large files because large I/O operations go directly to the disk and avoid the cache. Later releases will support scatter/gather I/O which changes the performance tradeoffs so that this improvement will be available even for big I/O xfers. I don't believe that the OS1.2 HPFS does read ahead at this time, but I'm not sure. There *is* a limited form of read ahead in that the cache blocks are 2K, so when we read in one sector we also read in the next three sectors. Also, when we open a file we read in a file description sector - like a UNIX FNODE. That sector is usually quad aligned so that the following three sectors brought in with it are your first 3 sectors of data, again read ahead. HPFS is highly successful at keeping files contiguous so those following sectors are nearly always the right ones. There is an HPFS, HPFS/386, available with the LANMAN product for server environments. It is incompatible with the real mode box - so you can't run real mode on such machines - but it's a couple of notches faster than the standard OS/2 1.2 HPFS. It supports the full access control (permissions) scheme, allows much bigger caches (8 megs or so) and does more read ahead. All of these features will "trickle down" to the non-server OS/2 environment in future releases. gordon letwin
seifert@sun1.ruf.uni-freiburg.de (Ulrich Seifert) (09/15/90)
gordonl@microsoft.UUCP (Gordon LETWIN) writes: >This HPFS can be configured to do write behinds; I think that may be the >default. This delays writes until the disk goes idle for a couple of >seconds or until the data gets too old (risky to leave unwritten for >too long a period of time) or until the cache gets too dirty. The >performance effect of this is threefold: ... Gordon, thank you very much for your explanations. Although I haven't seen benchmark results for the performance of the cache system yet it the technical part sounds very good. Maybe this is the right place to post a related question. Let us assume we have a power failure. Well, probably everybody thinks the damage from programs that unknowingly died in the machine is much bigger than damage arising from programs dieing unknowingly in the machine will bemuch bigger than everything what happens in the cache. Maybe but if we are doing transaction processing we should be sure that the data safely arrive on the disk after a commit. What I want to say is *NOT* that all caching with write behinds is nonsense. But maybe it is not really enough. I think there are many possible situations where an application should be notified that there is a problem with the power supply. Of course, I assume that the computer is equipped with an UPS. Most of the UPSs give a kind of warning if anything is wrong. I think it would be a great idea for OS/2 to set up a watchdog kind of interface to the UPS and broadcast a warning to very running application (for example within the PM to begin with). The file subsystem could save the cache and switch to a no-write-behind mode until the UPS signals that everything is o.k. again. The applications could write a kind of restart ile for the case that the power doesn't stabelizes any more or ignore the message and the user could go and check the status of his coffee machine instead of hurrying from one machine to the next and shutting everything down in the correct order. Wouldn't that be fantastic (and maybe one argument more to give OS/2 a try?). What do you think out there, maybe we can convince IBM/Microsoft that such a thing is a must-have. Ulf Ulf
d9mikael@dtek.chalmers.se (Mikael Wahlgren) (09/16/90)
In article <1990Sep15.154653.14659@sun1.ruf.uni-freiburg.de> seifert@sun1.ruf.uni-freiburg.de (Ulrich Seifert) writes: >What I want to say is *NOT* that all caching with write behinds is nonsense. >But maybe it is not really enough. I think there are many possible situations >where an application should be notified that there is a problem with the power >supply. Of course, I assume that the computer is equipped with an UPS. Most >of the UPSs give a kind of warning if anything is wrong. Well, if you have an UPS and the UPS has a power failure output, it wouldn't be hard to write a program that performes a DosShutdown-call, or sends QUIT- messages (or any other appropriate message) to the applications. My opinion is that there is sufficient possibilities to shutdown the system fast and gracefully in such a situation. Mikael Wahlgren d9mikael@dtek.chalmers.se
alistair@microsoft.UUCP (Alistair BANKS) (09/18/90)
As noted by Gordon Letwin, and as requested, Microsoft LanManager 2.0 does indeed have UPS support so that any server running LanMan 2.0 with UPS hardware and HPFS can be shut down cleanly when a power fault occurs. Alistair Banks Systems Group Microsoft