The following is a list of the priority 1, 2, and 3 bugs associated with Solstice DiskSuite 4.2. The priority and severity of the bugs is given in parentheses following the BugID number.
4155935 (P2/S2) -- Drives with the same non-zero serial number (from the SCSI inquiry command) are factored to a single drive, if a controller contains no unique drives it is not displayed in the Disk View screen in DiskSuite Tool. This behavior may not be appropriate.
4158835 (P2/S2) -- DiskSuite Tool appears to make determinations, beyond the kernel and metadb state, about the state of the metadevice based on the accessibility of components. For instance, if you are in DiskSuite Tool and remove power to a drive that has slices that are used by a metadevice that is not being accessed, the tool will display the failure before metastat(1M) sees the failure.
4068961 (P2/S2) -- Synchronous and asynchronous transactions to a trans logging metadevice in conjunction with page faults can lock each other out of the metadevice and hang the system. The workaround for this rare bug is to convert the application from a multithreaded application into a multiprocess application to avoid multithreaded contention for the address space lock, or disable UFS transaction logging on the device to which the application writes.
4150183 (P2/S2) -- If you have a drive failure on a recoverable metadevice (mirror/RAID) and you have file systems or applications that are not accessing the drive when the failure occurs, DiskSuite does not place the component or slice in the "Needs Maintenance" state because it has never accessed the partition and seen the error. The user could replace a drive that has not gone into an errored state. This would result in file system panics. To safely replace a device that has failed, but not been placed in the "Needs Maintenance" state by DiskSuite, you must cut off read/write access to the metadevice, decompose it into its components, replace the failed component, and reconstruct the device with the new component. Consult the Solstice DiskSuite 4.2 User's Guide for instructions on decomposing and restoring metadevices without data loss.
4113855 (P3/S3) -- High I/O on large filesystems with trans logs attached could cause poor performance or soft hangs. The problem was observed when the size of the trans log file for the filesystem was 150 Mbytes. When the size of the trans log was changed, the soft hangs seemed to go away. However, the machine's performance did degrade. The cause seemed to be in the trans device. The workaround is to remove the trans logs from the filesystem. This may not be the best solution for all customers, because when the logs are removed the length of time required for an fsck may be too great.