1. Private region at the beginning
Block zero of a sliced disk is used to hold the VTOC of the physical device. Nothing
should attempt to write to offset zero on any such disk, or it will place the contents
of the VTOC in jeopardy. File systems and boot blocks all offset at least one sector
when writing to a slice for exactly this reason. Private regions for VxVM also do this
to preserve the VTOC contents on that block.
A private region is placed at the beginning of a disk by default when that disk is
initialized. Block zero is protected by the fact that the data layout for a private
region does not place anything in location zero. The private region can also be
placed at the beginning of a disk during its encapsulation. The circumstances which
permit this are exceedingly rare, and typically only arise from careful manipulation
of the data ahead of time.

2. Private region at the end
A private region can be placed at the end of the disk if it is initialized with the '-e'
option to vxdisksetup. In so doing, no protection is granted to the critical VTOC
in block 0 so all subdisk offsets on this disk must be computed at N+1. It works, but
it is kind of a hack and can be confusing when you are trying to map to slices later.
An encapsulated disk is a disk with existing data to be preserved, such as the boot
disk, that is brought under Volume Manager control. In the case when a disk is
encapsulated, yet does not map all of its disk space to slices, the private regions are
often placed at the end of the disk. If free space exists at the end, that is where the
private region will be placed during the encapsulation process. Block zero is
'protected' in such cases by mapping a single-block subdisk at offset zero. That
subdisk is marked in such a way that it is not movable using conventional means.
VxVM Private Regions: Mechanics & Internals of the VxVM Configuration Database 11


3. Private region somewhere in the middle
The private region of a VxVM may even be at some arbitrary location within the
address space of the disk. This is the case when a disk is encapsulated, and the only
‘free’ space in which to place the private region is in the center of the disk. The most
common example of this is a boot disk encapsulation.
When a boot device is encapsulated, space for the private region is very typically
“stolen” from the last few cylinders of the swap space. Swap is shortened by the
required amount, and the private region slice is mapped into the now-available
diskspace. Since swap is almost never at the end of a disk, this places the new
private region somewhere in the middle of the disk.
This causes a number of problems. The most difficult is how to represent a single
private and a single public region on the disk. Recall that each region must be a slice,
and that slices are defined in terms of a starting point and offset. In the geometry of
our private-region-in-the-middle disk, we have some amount of data/public space, a
private region, then more data/public space. The private region is easy to map to a
slice. But what about the public region? It is non-contiguous; the private region
separates the two public data spaces. One way to solve this problem is to overlap the
two regions.
The public region is mapped to the entire disk, just as the backup slice (s2) is. The
private region is mapped to a slice as normal. This means that the private region lies
within the address space of both the public and private region's partitions. In order
to prevent a data volume from being created out of the space occupied by the
private region, VxVM must mask off that space in some way. It does this by creating
a subdisk within the public region which corresponds to the private region’s
location.These placement methods are necessary for dealing with encapsulated disks
in general and specifically with the boot disk. In most systems, VxVM manages the
boot device by encapsulating it. That disk has typically just been installed with the
Solaris operating system, and every bit of available space on the device has been
devoted to one file system or another in the standard OS install (or swap). Prior to
release of the Solaris 8 Operating Environment, this almost always meant two
things: the root file system begins at cylinder zero on the disk and the primary swap
partition is somewhere in the middle of the disk. These two conditions gave rise to
two special subdisks in rootdg: rootdisk-B0 and rootdiskPriv.
rootdisk-B0
The root file system beginning on cylinder zero will include the critical VTOC
block at offset 0 of the disk. UFS file systems and boot blocks are engineered
to skip over this critical information, so the VTOC data is protected by the
nature of the data on the slice. For a volume, this may or may not be the case.
Suppose that the encapsulated boot disk is recycled: rootvol and any other
subdisks, volumes or plexes on the disk are relocated to other disks, then new
12 VxVM Private Regions: Mechanics & Internals of the VxVM Configuration Database • July 2000
volumes are created from the now-vacant space formally occupied by the root
file system. There is no inherent protection for block zero, it is now at risk of
being over-written.
VxVM resolves this problem by creating a special subdisk which maps block
zero on the root disk, ‘rootdisk-B0’. This subdisk is configured in such a
way that it may not be moved or deleted without specific user intervention.
With rootdisk-B0 now guarding block zero of the disk, any new volumes
created here cannot overlap that space. rootdisk-B0 serves no other
purpose than to guard the VTOC.
rootdiskPriv
Because our boot device was full before encapsulation, VxVM took a small
amount of space from the swap device to create the private region. This very
likely placed the private region in the middle of the disk, which caused the
public and private regions to overlap on this device as was discussed earlier
in this section.
VxVM must find some way to ensure that as this disk is re-used as the system
ages, no volume is created in that part of the public region which corresponds
to the private region’s location. It does this by creating an unattached subdisk
in this space. The ‘rootdiskPriv’ subdisk guards the space in which the
private region resides.

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.