Browse Prior Art Database

Method and Means of Reducing OS Installation Time on Low-End RAID Controllers

IP.com Disclosure Number: IPCOM000012428D
Original Publication Date: 2003-May-07
Included in the Prior Art Database: 2003-May-07
Document File: 2 page(s) / 45K

Publishing Venue

IBM

Abstract

This disclosure proposes a "volatile write-back mode" implementation. In this instance, the RAID configuration maintains its original write-back/write-through configuration setting. In a separate part of the configuration is the volatile write-back mode setting which consists of a counter. At boot time, if this counter is non-zero, write-back mode is forced on the controller during that boot period. When the system is rebooted, the counter (if non-zero) is decremented. The counter is initially set by a command from the host.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

  Method and Means of Reducing OS Installation Time on Low-End RAID Controllers

   There are two caching modes in ServeRAID: write-through and write-back. In write-through mode, the RAID controller ensures that any data is written to disk before informing the host that a write operation is complete. In write-back mode, the RAID controller only moves the data to the controller cache before informing the host that the write operation is complete. The data is then written to disk independently by a background flush process. In high-end RAID controllers, the controller cache is battery-backed. This means that if a system crashes after the controller has acknowledged a write operation but before the flush algorithm has flushed the cached data to disk, the cached data will still be in cache when the system is brought back up. The data can then be flushed as normal and no data is lost. In low-end controllers, no such battery-backup exists. The controller can still be run in write-back mode but all data in cache is lost when a system crashes. Because of this, ServeRAID controllers without battery-backup are defaulted to write through mode. While this protects the user's data, it causes a significant performance degradation.

     In lab tests, the following times were noted for installation of Windows 2K on a 3-drive RAID 5 array:

     Write-back mode w/o background synchronization: 64 minutes Write-through mode w/o background synchronization: 91 minutes Write-back mode with background synchronization: 72 minutes Write-through mode with background synchronization: 125 minutes From these results, it is easy to see, that regardless of synchronization, installing while in write-through mode is a significant hit to overall installation time.

     For runtime operation, data integrity for the majority of users is more important than performance (which is why they bought a low-end controller). However, for OS installation, data integrity is not an issue. If a system crashes in the middle of an OS installation, the installation is not going to be able to pick up where it left off...rather the installation would be restarted from scratch. Therefore, it would be advantageous to install in write-back mode and switch back to normal user-desired operational mode (albeit write-through or write-back) after installation.

     ServerGuide started going down this path a few years ago but hit a roadblock with what "user-desired operational mode" is. Take the following scen...