|
HP OpenVMS Systemsask the wizard |
|
The Question is: Header. How operate-correct with SCSI disks or give him a second chance to be useful , while error count is growing up, badlog.sys rize and particial files cannot accessed. Illus here. ----------------------------------------------- Meaning of question. 1. Are the Bad Block Locator Utility(Analize/Media DCL coomand) is now obsolete for this type(SCSI) device or not? Is this utility insert,automaticaly, bad blocks location(placement) in file on tested volume: ddccu:[mfd]badblk.sys, to avoid a problem whith using trusted pplaces. 2. Are the Analise/disk is now obsolete for this type(SCSI) device or not? Is this utility insert,automaticaly, bad blocks location(placement) in file on tested volume: ddccu:[mfd]badlog.sys, to avoid a problem whith using trusted pplaces. ----------------------------------------------- I desire to be sure what i have workable tools, even if it is from maintanance Tool kit. Some Thing like annoing MS Scandisk. This is problem for me, becouse i am not sure with data integrityn whith all ot these RAID-nn solution, while logical fault from ordinary file, which is represent entry level of data input, may destroy all deepthinkig secure system. ----------------------------------------------- It will be good, what storage device self repaire this problem like DSSI and HSC, e.t.c., but it is good to have transparent ability and possibility to assuranse. With best regards ans great respect from long term VMS worshipper. Live long and prosper. The Answer is : The ANALYZE/MEDIA (BAD) utility, BAD*.SYS files, and the related tools are typically not required on modern disks; OpenVMS, the controllers and/or the disks transparently and volume shadowing or a RAID controller all conspire provide the appearance of a logically perfect storage medium. That said, there are cases where the BADBLK.SYS file will be used to store bad blocks. Failing disk blocks are typically revectored to spare blocks as failing (or failed) blocks are detected, usually on write verify or on detection of corruption on read. The implementation details do differ depending on the particular disk device involved, and can involve the disk device, the controller, and/or the host operating system software. With more recent SCSI devices and OpenVMS V6.2 and later, the AWRE (Automatic Write REmapping) and ARRE (Automatic Read Remapping) mechanism is available -- when disabled, the host handles the revectoring. When AWRE is enabled, the controller and the disk handle bad blocks and the drive appears perfect (until there are more bad blocks than spare blocks). When accessing a directly-connected disk with AWRE and ARRE disabled, OpenVMS performs the defect management. If on a SCSI disk WRITE (using the XQP or using host-based shadowing) a hard error is encountered, OpenVMS will issue a REASSIGN command to the disk and the disk will revector the block, adding the bad block to its "GLIST" -- this is the SCSI equivalent of the DSA structure known as the Replacement and Caching Table (RCT). If the defect list is full or if the disk is incapable of REASSIGN, OpenVMS then marks the block bad in BADBLK.SYS. If on a SCSI disk READ a hard error is encountered and the disk is a member of a volume shadowset, then the data is read from another shadowset member and returned to the user without error. A REASSIGN is issued against the failing block, and the good data is written back to the disk. This causes known-good data to be written into a new block, and the failing block is added to the GLIST. If on a SCSI disk READ a hard error is encountered and the disk is not a member of a volume shadowset, the data is lost, and a parity error (SS$_PARITY) error is returned. A REASSIGN cannot be issued against the bad block, because there is no good data for the new block. OpenVMS will set a forced-error flag in the file header, and an associated error (SS$_FORCEDERROR) will be reported to accessors. Upon the deletion of a file with a forced error, OpenVMS will start with the last block of the file and work backwards until it finds the bad block. VMS will attempt to issue a REASSIGN if the device is capable of it. If the defect list is full or the device is incapable of REASSIGN commands, then OpenVMS will add the bad block into BADBLK.SYS. If a file on a SCSI device is not processed using volume shadowing or the XQP, the bad block cannot be corrected. The system pagefile -- when operating on a volume that is not shadowed -- is an example of a file access that does not use the XQP, and that thus cannot be revectored. Thre ability of OpenVMS to revector bad blocks under the pagefile or other non-XQP-accessed file requires the re-creation of the file, while the ability to tolerate and to recover from such disk errors without the re-creation of the file requires the use of host-based volume shadowing or of controller-based RAID. Related tools include the (Freeware) RZDISK and the ANALYZE/MEDIA tools. RAID storage controllers and host-based volume shadowing and similar constructs are all intended to reduce the effects of hardware failures on the host operating system and to particularly return good data to the host (and to the revector) in the event of uncorrectable disk block errors. BADLOG.SYS is used as a repository of (potentially) failing disk blocks. Known-bad blocks are stored in BADBLK.SYS. You can request a scan of bad blocks (using BADBLOCK_SCAN) during file deletion, by setting the FH2$V_BADBLOCK bit in the file header. DSA disks provide a forced-error flag, SCSI devices do not -- this means that reads can report data errors only on DSA disks. The ANALYZE/DISK utility verifies the file structure. The other central component involved in this area is the BACKUP utility, as this is one of the core tools to recover from errors. Topics specific to unintential initialization or the overwriting of disk and tape media include (1286) and (6990). For errors resulting from file structure, directory structure, or file structure corruptions, please see topics such as (1213), (4088), (4571), (5071), (5553), (5719), (6021), (6234). If you want to overwrite or erase the data on the media for reasons of security or other related reasons, related topics include (841), (3926), (4286), (4598), and (7320). (Do note that ANALYZE/MEDIA (BAD) will save and will write the addresses of bad blocks into a low-level on-disk structure known as the Detected Bad Block File (DBBF), which will mean that there will potentially be one or more blocks on a disk that will not contain the erasure pattern even after a full BAD pass. This is documented in the ANALYZE/MEDIA (BAD) manual.)
|