More on Write Cache flushing

Q
>I recently noticed a DriverGestalt status call called 'flus'. What is 
>this? I can't find it documented anywhere.
 
A
The  'flus'  DriverGestalt  was introduced in System 7.6 and was documented in TN1090, 
under the file manager, cache-related items..

----------
File Manager

The File Manager provides services for storage and retrieval of 
disk-based information on Mac OS-compatible computers. Mac OS 7.6 
includes several changes in the File Manager's implementation, providing 
improved performance and reliability. The following describes new 
features and facilities provided in the Mac OS 7.6 File Manager 
implementation:

Cache-Related:
......
*	Many high-performance disk drives and some disk drivers utilize a 
private write cache mechanism independent of the File Manager's cache to 
enhance performance. Because of this, it is possible that even though 
the file system has carried out appropriate writes to a disk driver when 
flushing a volume, some of the information may still reside in the disk 
drive's or disk driver's cache and can be lost in the event of a power 
failure. In response to this possibility, a disk driver that supports 
the DriverGestalt 'flus' selector is called with the DriverConfig 'flus'
 selector whenever that disk volume's cache is flushed in response to a 
File Manager FlushVol or UnmountVol request. 
 ------

my original note was ...

 ------
Many high-performance disk drives available for Macintosh computers utilize an
 on-board hardware write cache mechanism. Although these devices can  
enhance disk performance, they also require special software consideration 
to avoid the loss of data.

Most disk drivers both SCSI and IDE now properly handle the flushing of
disk cache on shutdown. Application developers however have no control
over this.  For instance many a database developer has written to DTS
wondering why a filesystem FlushVol didn't really commit data to thier
disk medium before a powerfail.  Even though the filesystem properly
cleared its cache, and performed the apropriate writes to the disk
driver, the driver had no way of distinguishiing a  FlushVol or
FileSystem Cache flush from any other write operation.

What I propose is that a mechanism be constructed whereby the  
FileManager can inform a disk driver that a flush has just occured.


Since any changes will require backward compatibility we need a way to
determine if a disk can support these features. 

I propose the following:

1) The FileManager issues a driverGestalt call to the disk driver with
a  'flus' selector to query if the disk driver can support a diskcache
flush.

2) whenever the FileManager does a FlushVol it will then issue a csFlush
(or whatever) command down to the disk driver, which will be
responsible for any cache synchronization operations.

Since this is handled by the disk driver,  it will do the specifics for
that media.

I also would suggest some unused  Volume information bit be assigned to
indicate that this volume is capabile of write cache synchronization
operations. This might be handy for database developers to know about.

----

the response from engineering was:

I added the kdgFlush Driver Gestalt selector, the kdcFlush Driver Configure selector,
 the DriverConfigParam struct, the GetDriverGestaltFlushResponse #define, 
and the DriverGestaltFlushResponse struct.

FlushDriverCache or FlushDriverIdleProc will call disk drivers that support flushing 
whenever FlushVol or UnmountVol is called. The driver will be asked via DriverGestalt 
if it supports flushing and needs to be flushed. If it replies "yes" to both, then a 
DriverConfig flush call is made to the driver. Drivers that don't support 
DriverGestalt are not called. FlushDriverIdleProc is used to flush the drive only 
if the FlushVol call was made asynchronously
 (when the File Manager cannot safely tell the driver to flush).

--------

Back to my homepage