Why Does Rootvol Have A Subdisk Labeled "rootdisk-b0"?

Document ID: 231259 http://support.veritas.com/docs/231259 Why does rootvol have a subdisk labeled "rootdisk-B0"? Details: A quick overview: The B0 subdisk is there as a protective mechanism when an encapsulated file system begins at cylinder 0 of the disk. Since VERITAS Volume Manager (VxVM) does not allow access to the bootblock (first sector) of a disk, it must relocate that information somewhere else; thus it creates the B0 subdisk as a replacement for the area of the volume that would normally be on the bootblock sector. DO NOT REMOVE THIS SUBDISK! It is vital for the integrity of the rootvol and can be difficult to remake if it is deleted. A more detailed overview: File systems are built to not interfere with the bootblock. They generally do not touch any data until 8k into the device, where they store their superblock. Applications that use raw partitions, however, do not make the same concessions. They tend to want to use all of the space. Since the space allocated by VxVM can be dynamically re-adjusted and it is never possible to rely on a file system being on that particular area of the disk, VxVM must protect that region. It does this by shifting the start of the Public Region by one sector, preventing VxVM from ever using the first sector of the disk. The file system that started on cylinder 0, however, still needs to be able to reference that sector so that all of its offsets will be in line. To facilitate this the B0 subdisk is created and placed onto the beginning of the volume as a replacement for the bootblock that can no longer be accessed. When looking at the VTOC of an encapsulated disk, it can be seen that the Public Region (tag 14) is defined the same as the BACKUP slice, or the entire disk (slice 2). This gives the impression that the Public Region is the same size as the disk. * Sector

Last

First

* Partition

Tag

Mount Directory 381023 445535 BACKUP ---------> 2 Public ----------> 2052287 Private ---------->

5 3 4

Sector

Count 0

0

2

00

1

3

01

00 14 15

Flags

6

381024

0 01 01

0 4

2050272 00

Sector 381024 64512

2052288 2052287 2052288 2016 445536

2052287 522144

967679 However, by looking at the VERITAS disk label that was put on the disk, it will become apparent that the Public Region is actually defined somewhat differently.

# vxdisk list c0t3d0s2 Device: c0t3d0s2 devicetag: c0t3d0 type: sliced hostid: hyde-machine disk: name=rootdisk id=875029155.1028.hyde group: name=rootdg id=875029151.1025.hyde flags: online ready autoconfig autoimport imported pubpaths: block=/dev/dsk/c0t3d0s3 char=/dev/rdsk/c0t3d0s3 privpaths: block=/dev/dsk/c0t3d0s4 char=/dev/rdsk/c0t3d0s4 version: 2.1 iosize: min=512 (bytes) max=248 (blocks) public: slice=3 offset=1 len=2050272 private: slice=4 offset=1 len=2015 ... Here, it can be seen that the Public Region is defined on slice 3, its offset is 1 sector, and it is 2050272 sectors in length. The Private Region also is offset by 1 sector. So the map of an encapsulated disk looks like: Entire Disk

0------------------------------------------------------2052287

Public Slice Public Region

0------------------------------------------------------2052287 1------------------------------------2050272

Private Slice 2050272-----2052287 Private Region 2052287

2050273----

Notice that Public Region actually uses the first sector of the slice where the Private Region is defined. The Private Region will always have an offset of 1 sector with sliced disks-- this space is counted on. A quick look at "vxprint -ht rootvol" will show why that first sector of the Private Region is counted on being available: # vxprint -ht rootvol Disk group: rootdg V NAME PL NAME SD NAME

USETYPE VOLUME PLEX

v rootvol root pl rootvol-01 rootvol sd rootdisk-B0 rootvol-01 sd rootdisk-02 rootvol-01

KSTATE STATE LENGTH READPOL PREFPLEX KSTATE STATE LENGTH LAYOUT NCOL/WID DISK DISKOFFS LENGTH [COL/]OFF DEVICE ENABLED ACTIVE 381024 ROUND ENABLED ACTIVE 381024 CONCAT rootdisk 2050271 1 0 rootdisk 0 381023 1

c0t3d0 c0t3d0

By looking at the DISKOFFS or disk offset of rootdisk-B0, it will be seen that it is at 2050271. This is the offset from the beginning of the Public Region. A little math will produce: 2050271 + 1 = 2050272 (or, the first sector of the Private Region slice)

Thus, the B0 subdisk is not a relocation of the *bootblock*, but a relocation of the start of the file system that was created over the bootblock. Products Applied: Volume Manager for UNIX/Linux 3.0 (Solaris), 3.0.1 (Solaris), 3.0.2 (Solaris), 3.0.2.1(Solaris), 3.0.3 (Solaris), 3.0.4 (Solaris), 3.1 (Solaris), 3.2.2.0 (AIX) Last Updated: November 11 2000 01:26 AM GMT Expires on: 365 days from publish date Subscribe Via E-Mail IconSubscribe to receive critical updates about this document Subjects: Volume Manager for UNIX/Linux Application: Documentation, Faq, Informational Languages: English (US) Operating Systems: HP-UX 10.2, 11.0 Solaris 2.3, 2.4, 2.5, 2.5.1, 2.6, 7.0 (32-bit), 8.0 (32-bit) Symantec World Headquarters: 20330 Stevens Creek Blvd. Cupertino, CA 95014 World Wide Web: http://www.symantec.com, Tech Support Web: http://entsupport.symantec.com, E-Mail Support: http://seer.entsupport.symantec.com/email_forms, FTP: ftp://ftp.entsupport.symantec.com or http://ftp.entsupport.symantec.com THE INFORMATION PROVIDED IN THE SYMANTEC SOFTWARE KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. SYMANTEC SOFTWARE DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL SYMANTEC SOFTWARE OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES,EVEN IF SYMANTEC SOFTWARE OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.