在{dy}次修改快照源的数据时，需要将快照源的数据拷贝到COW设备上。假定快照源的数据所在的位置称为旧chunk，完成上述需要三个步骤：
每个快照都有一种例外信息管理机制，叫做例外仓库，通过快照结构的store域指向。例外仓库结构exception_store给出了管理例外的方法：
struct exception_store {
void (*destroy) (struct exception_store *store); //在使用完之后销毁例外仓库
int (*read_metadata) (struct exception_store *store); //目标器在调用这个函数之后才能读取COW设备
int (*prepare_exception) (struct exception_store *store, struct exception *e); //查找保存下一个例外的位置
void (*commit_exception) (struct exception_store *store, struct exception *e, void (*callback) (void *, int success), void *callback_context); //用这个例外更新元数据
void (*drop_snapshot) (struct exception_store *store); //快照无效，在元数据中记录下来
void (*fraction_full) (struct exception_store *store, sector_t *numerator, sector_t *denominator); //返回快照有多满
struct dm_snapshot *snap; //回指到所属快照
void *context; //例外仓库的上下文
};
在这些方法中，prepare_exception相当于第1个步骤，可以理解为例外信息准备；而commit_exception相当于第3个步骤，即例外信息提交。
当前的快照实现支持两种方式的例外仓库，一种称为{yj}性例外仓库，一种为非{yj}性例外仓库。
非{yj}性例外仓库是一种简单的例外信息管理机制。元数据只存在内存，即快照结构的例外表。在COW设备上只保留快照数据，并且是根据例外发生的先后顺序存放的。一旦关机，非{yj}性例外仓库的元数据便丢失了，快照即失效了。
按照这一机制，非{yj}性例外仓库只需要一个变量，记录在COW设备上保存（快照源的）下一个数据的起始扇区编号。
struct transient_c {
sector_t next_free;
};
计算这个编号的方法非常简单。只需要确保这个位置开始的一个chunk没有超出COW设备的长度，即可以将它作为快照源的数据的存放位置。同时修改这个编号，往前推进一个chunk。当然如果这个位置的chunk已经超出COW设备的长度，则返回一个错误值，由上层调用负责来将这个快照置为无效状态。
对于非{yj}性例外仓库，前面描述的三个步骤的第3步是不必要的。因为例外信息已经记录在快照结构的例外表中。因此commit_exception不需要做特定的元数据记录，直接调用上层设定的例外提交回调函数即可。
非{yj}性例外仓库不在COW设备上保存元数据，因此也无所谓读取。故read_metadata函数也直接返回0。
与此相对应，除了保存快照源的数据外，{yj}性例外仓库还将元数据保存在COW设备上。{yj}性例外仓库的上下文结构如下：
struct pstore {
struct dm_snapshot *snap; //回指到快照
int version;
int valid;
uint32_t exceptions_per_area; //每个区域含有的例外个数
/* Now that we have an asynchronous kcopyd there is no need for large chunk sizes, so it wont hurt to have a whole chunks worth of metadata in memory at once. */
void *area; //保存一个chunk的元数据
uint32_t current_area; // Used to keep track of which metadata area the data in 'chunk' refers to
uint32_t next_free; //用于例外的下一个空闲chunk
uint32_t current_committed; //The index of next free exception in the current metadata area
atomic_t pending_count;
uint32_t callback_count;
struct commit_callback *callbacks;
struct dm_io_client *io_client;
};
COW设备的布局如图所示。COW设备空间以chunk为单位，{dy}个chunk保存了标识该快照的一些基本信息：包括魔术（0x70416e53）、有效标志、版本号以及以扇区为单位的chunk长度。之后的空间被分成多个区，每个区（area）由一个chunk的元数据和相应chunk数目的数据组成，形成交隔的布局。区的{dy}个chunk用来保存多个例外，其数目可以计算出来，保存于exceptions_per_area域。这样，元数据后是exceptions_per_area个chunk数据。因此一个区总共的chunk数是exceptions_per_area+1。
在这样的设计下，空闲chunk编号next_free分配算法如下：初始从第2个开始，即跳过头信息chunk和{dy}个源数据区域。之后不断增1，但是需要中间的元数据区。即当next_free在增加后，如果模一个区的chunk数为1，表明此时，next_free指向元数据区，因此再将其加1。
注意到，元数据也是以chunk为单位写入磁盘的。在pstore结构中，area保存了一个chunk的元数据，current_area记录了它的区号，current_committed记录了在当前区中的下一个空闲例外的编号。提交的例外信息会首先保存在area中，一旦所有发起的数据均已经写入了COW设备，或者说一个区的所有chunk的数据都已经写入COW设备，则会将area中的元数据也写入（提交）到COW设备中。并根据需要确定是否要转到下一个区，转之前会先将下一个区在磁盘上的信息清零。
由于元数据也保存在COW设备上，{yj}性例外仓库可以使得快照在系统重启之后依然有效。read_metadata负责在快照启动时重建例外表。这个过程是：从COW设备读取头信息，确保魔数、有效性及版本号等信息正确。然后循环读取每个area的元数据，并根据其中的映射信息构造快照结构的例外表，直到映射信息中new_chunk为0，这表明到达了空闲的chunk。
