In persistent_prepare(), when incrementing the next_free field and checking
for the location for the next metadata area, it doesn't seem to account for
the header chunk at the beginning of the cow device.

For example: 
   chunk_size = 32 (16k)
   exceptions_per_area = 1024
   stride = 1025

   The header is chunk 0, the first metadata area is chunk 1, and the first
   data area is chunks 2 through 1025. When next_free equals 1024 (the second-
   to-last data chunk in the first area), it will be incremented to 1025, then
   mod'd with stride to get 0, and then incremented again to 1026. This
   effectively skips the last data chunk in the first data area and sets
   next_free to the chunk for the second metadata area. I'm guessing this
   will eventually look like data corruption if the snapshot tries to read
   data from that chunk, since it will eventually be overwritten by metadata.

This patch corrects this by checking for a mod value of 1, instead of 0.
Another possible solution would be to change the prefix-increment to a
postfix-increment.  [Kevin Corry]

--- diff/drivers/md/dm-exception-store.c	2003-02-13 10:42:23.000000000 +0000
+++ source/drivers/md/dm-exception-store.c	2003-02-25 14:44:36.000000000 +0000
@@ -459,7 +459,7 @@
 	 * into account the location of the metadata chunks.
 	 */
 	stride = (ps->exceptions_per_area + 1);
-	if (!(++ps->next_free % stride))
+	if ((++ps->next_free % stride) == 1)
 		ps->next_free++;
 
 	atomic_inc(&ps->pending_count);