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.

* First
Sector Last
* Partition Tag Flags Sector Count Sector
Mount Directory
0 2 00 0 381024
381023
1 3 01 381024 64512
445535
BACKUP ---------> 2 5 00 0 2052288 2052287
Public ----------> 3 14 01 0 2052288
2052287
Private ----------> 4 15 01 2050272 2016 2052287
6 4 00 445536 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 0------------------------------------------------------2052287

Public Region 1------------------------------------2050272

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

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 USETYPE KSTATE STATE LENGTH READPOL PREFPLEX

PL NAME VOLUME KSTATE STATE LENGTH LAYOUT NCOL/WID
SD NAME PLEX DISK DISKOFFS LENGTH [COL/]OFF DEVICE

v rootvol root ENABLED ACTIVE 381024 ROUND -

pl rootvol-01 rootvol ENABLED ACTIVE 381024 CONCAT -
sd rootdisk-B0 rootvol-01 rootdisk 2050271 1 0 c0t3d0
sd rootdisk-02 rootvol-01 rootdisk 0 381023 1 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.