tests: do not truncate too far
authorArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
Fri, 3 May 2013 05:57:32 +0000 (08:57 +0300)
committerArtem Bityutskiy <artem.bityutskiy@intel.com>
Fri, 3 May 2013 06:12:03 +0000 (09:12 +0300)
This patch changes the '_create_random_sparse_file()' function behavier a
little and teaches it to not truncate files too far. For example, if we
asked '_create_random_sparse_file()' to create an 8193 bytes sparse file,
it could do the following:

1. Map the first 4KiB block
2. Map the second 4KiB block
3. Truncate to 12KiB
4. And at the end truncate to 8183 bytes

This worked fine on ext4 - we ended up with a file with 2 first blocks mapped
and an unmapped block at the end. However, on btrfs this leads to a file with
all 3 blocks mapped (I assume 1 block = 4KiB). And this is not a bug, this is
just how btrfs allocates blocks and we cannot, generally speaking, make any
assumptions about the allocation algorithms.

This patch changes '_create_random_sparse_file()' and makes it avoid truncating
files too far. Namely, we will truncate only to the end of the last block.

Now the tests pass on btrfs (kernel version 3.8.6).

Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
tests/helpers.py

index 2b771b8b97c3aa27ca63cf4f065e370ae0b3747a..22a72fcb61f37ae108773bdca3a6a6a87751ba7f 100644 (file)
@@ -37,7 +37,7 @@ def _create_random_sparse_file(file_obj, size):
             file_obj.seek(block * block_size + seek)
             file_obj.write(chr(random.getrandbits(8)) * write)
         else:
-            file_obj.truncate((block + 1) * block_size)
+            file_obj.truncate(block * block_size)
 
         return map_the_block