Path: utzoo!attcan!uunet!microsoft!gordonl
From: gordonl@microsoft.UUCP (Gordon LETWIN)
Newsgroups: comp.os.os2.misc
Subject: Re: HPFS and cache controllers
Summary: HPFS cache
Keywords: HPFS cache
Message-ID: <57439@microsoft.UUCP>
Date: 14 Sep 90 16:54:31 GMT
References: <1990Sep6.141036.11041@sun1.ruf.uni-freiburg.de>
Distribution: comp
Organization: Microsoft Corp., Redmond WA
Lines: 51

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