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. --- linux-2.4.20a/drivers/md/dm-exception-store.c 2002/12/31 14:59:10 +++ linux-2.4.20b/drivers/md/dm-exception-store.c 2003/02/17 17:26:01 @@ -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);
