HP-UX 11i v3 Using LVM Logical Volume Snapshots (September 2010)

5
When a write comes to the original logical volume on the snapshot tree, the unshare units to which
the write is destined are unshared first. This means that the data in these unshare units are copied to
its predecessor before the write to the original logical volume proceeds. This is referred to as a copy-
before-write operation (CBW). When a write comes to a snapshot logical volume, two CBW
operations might be required.
Building on the snapshot tree depicted in Figure1, Figure 2 shows the contents of the unshare units of
each logical volume on the snapshot tree. The arrow indicates that the data in the unshare unit is
shared with its successor. The initial contents of the original logical volume LV was the same as that of
its first snapshot S0. For example, S0 and S1 initially shared all their data with the original logical
volume LV and a write comes to S1’s second unshare unit containing B. Because S1 shares data with
its successor (LV) and predecessor (S0) for this unshare unit, the original data B is copied to S1 from
LV, then to S0 from LV, and then the new data X is written to S1. At this point, S0 and S1 have the
second unshare unit completely unshared. If a subsequent write Y comes to the third unshare unit of
the original logical volume LV, the original data C is copied over from LV to S1 and then the write Y
is allowed to proceed. Only the third unshare unit of S1 is unshared; S0 still shares this data with S1.
Figure 2: Snapshot tree unshare units
A
B
Y
D
A
X
C
D
A
B
C
D
LV S1 S0
If a data unshare operation fails, the data contained in the snapshot logical volume no longer remains
point-in-time. Such a snapshot logical volume is marked as inoperative. After a snapshot becomes
inoperative, subsequent read and write operations on the snapshot fail. When a space-efficient
snapshot logical volume becomes inoperative, its pre-allocated extents are freed and available as free
extents in the volume group.
When a snapshot that has a file system mounted on it becomes inoperative, you cannot access the file
system contents or list the files in the file system. However, if the file system is mounted as read-only on
a snapshot logical volume (that is configured as read-write or read-only), you can access the file
system contents even after the snapshot becomes inoperative. Mounting a file system on an
inoperative snapshot fails.
For a fully-allocated snapshot, the extent to which the data is unshared is already allocated at the time
of snapshot creation. For a space-efficient snapshot, the extent is picked from the pre-allocated pool of
extents, such that the extent or the set of extents picked satisfies the allocation policy of the snapshot.
As subsequent data unsharing continues to pick extents from the pre-allocated pool, there might be an
instance when no extent can be picked from the pre-allocated pool either because all the extents in
the pool have been used up or the remaining extents in the pool do not satisfy the allocation policy of
the snapshot logical volume. In these cases, the snapshot is referred to as over-committed. It is also