The write policies specify if the controller sends a write-request completion signal when the data is in the cache or after it has beenwritten to the disk.• Write Through — The controller sends a write-request completion signal only after the data is written to the disk. Write-through caching provides better data security than write-back caching, since the system assumes that the data is available onlyafter it has been safely written to the disk.• Write Back — The controller sends a write-request completion signal as soon as the data is in the controller cache but has notyet been written to disk. Write back caching may provide improved performance since subsequent read requests can retrievedata quickly from the cache then from the disk. However, data loss may occur in the event of a system failure which preventsthat data from being written on a disk. Other applications may also experience problems when actions assume that the data isavailable on the disk.• Force Write Back — The write cache is enabled regardless of whether the controller has a battery. If the controller does nothave a battery and force write-back caching is used, data loss may occur in the event of a power failure.The Disk Cache policy applies to readings on a specific virtual disk. These settings do not affect the read-ahead policy.NOTE:• Controller non-volatile cache and battery backup of controller cache affects the read-policy or the write policy that acontroller can support. All PERCs do not have battery and cache.• Read ahead and write back requires cache. Therefore, if the controller does not have cache, it does not allow you to setthe policy value.Similarly, if the PERC has cache but not battery and the policy is set that requires accessing cache, then data loss mayoccur if base of power off. So few PERCs may not allow that policy.Therefore, depending upon the PERC, the policy value is set.Deleting virtual disksDeleting a virtual disk destroys all information including file systems and volumes residing on the virtual disk and removes the virtualdisk from the controller’s configuration. When deleting virtual disks, all assigned global hot spares may be automatically unassignedwhen the last virtual disk associated with the controller is deleted. When deleting the last virtual disk of a disk group, all assigneddedicated hot spares automatically become global hot spares.You must have the Login and Server Control privilege to perform delete virtual disks.When this operation is allowed, you can delete a boot virtual drive. It is done from sideband and the independent of the operatingsystem. Hence, a warning message appears before you delete the virtual drive.If you delete a virtual disk and immediately create a new virtual disk with all the same characteristics as the one that was deleted,the controller recognizes the data as if the first virtual disk were never deleted. In this situation, if you do not want the old data afterrecreating a new virtual disk, re-initialize the virtual disk.Checking virtual disk consistencyThis operation verifies the accuracy of the redundant (parity) information. This task only applies to redundant virtual disks. Whennecessary, the check consistency task rebuilds the redundant data. If the virtual drive has a degraded status, running a checkconsistency may be able to return the virtual drive to ready status. You can perform a consistency check using the web interface orRACADM.You can also cancel the check consistency operation. The cancel check consistency is a real-time operation.You must have Login and Server Control privilege to check consistency of virtual disks.NOTE: Consistency check is not supported when the drives are set up in RAID0 mode.200
