Automatic naming mechanism for storage subsystem devices given their physical location within the subsystem.
Original Publication Date: 2001-Sep-16
Included in the Prior Art Database: 2003-Jun-20
Disclosed is a mechanism for automatically naming storage subsystem devices given their physical location within the subsystem. When configuring a storage subsystem it is desirable to know the physical positioning of the storage devices (disks) in the subsystem, and to have the ability to control the naming of the physical devices at the operating system level. Most operating systems automatically name devices (assign a handle), e.g. in order of discovery, or in increasing order of device serial number, so the device name usually does not relate to a physical location, nor is it easy to determine the name when you know the physical location and vice versa. Relating a device to a physical location is important for identifying and replacing a failed device, maintaining a logical structure in a subsystem, and for fault tolerance. For example, in a subsystem consisting of 6 physical storage devices (disks), Disks 1 to 3 are configured as a RAID-0 array at site A and disks 4 to 6 as a RAID-0 array at site B. The RAID-0 array at site B is a mirrored copy of the RAID-0 array at site A. That is, the 6 disks constitute a single RAID-10 array split across two sites (Figure 1). The two sites may be different disk enclosures, rooms, or even buildings. If one site suffers a catastrophic failure, the data is still available at the other (Figure 2). However if a maintenance error is made, for example disk 3 is located at site B and disk 6 is located at site A, and such a failure occurs, the data is completely lost (Figure 3). Such an error is easily made, and not evident at the time. In the AIX operating system, physical disk drives are allocated a "pdisk" name, such as "pdisk0", "pdisk1" etc., generally in ascending serial number order (so the lowest serial number is pdisk0). Drives are usually contained in slots in enclosures, and each slot has a unique slot number. Combined with the enclosure name this gives a unique location identifier for the disk. However, there is no easy way to correlate pdisk names with location identifiers. The disclosed mechanism allows the user to define and maintain a mapping between location identifiers and pdisk names using a database. In enclosure FRED, with 16 drive slots, there are location identifiers FRED01 to FRED16. Every disk that is inserted into slot FRED01 is always assigned the pdisk number associated with FRED01 in the database. The pdisk name is stored on the physical disk drive in a reserved section, not available for customer use. In enclosure FRED, the user assigns location FRED01 to pdisk1, and then moves the disk from FRED01 to JOHN05 in enclosure JOHN. The disk is marked as pdisk1, but will attempt to be assigned the pdisk number associated with location JOHN05 (say pdisk23). The software in the subsystem notes the change and alerts the system administrator, thus reducing the risk of erroneous maintenance. This scheme advantageously allows users to replace a failed device without altering the allocation of pdisk names in the subsystem. Using the example of a 6-disk RAID-10 array, if the user has assigned Disk 1 the name pdisk100, and Disk 1 subsequently fails, when the disk is replaced the new disk will be assigned the name pdisk100, thus maintaining the logical and physical subsystem configuration especially important in a complex storage subsystem (>1000 disk devices). This scheme automates this task, as well as protecting from erronous 1