ext4: correctly migrate a file with a hole at the beginning
authorEryu Guan <guaneryu@gmail.com>
Sat, 4 Jul 2015 04:03:44 +0000 (00:03 -0400)
committerTheodore Ts'o <tytso@mit.edu>
Sat, 4 Jul 2015 04:03:44 +0000 (00:03 -0400)
commit8974fec7d72e3e02752fe0f27b4c3719c78d9a15
tree0eeac0b96a66c1a21f0e5d7e293238e30a927ea8
parentd6f123a9297496ad0b6335fe881504c4b5b2a5e5
ext4: correctly migrate a file with a hole at the beginning

Currently ext4_ind_migrate() doesn't correctly handle a file which
contains a hole at the beginning of the file.  This caused the migration
to be done incorrectly, and then if there is a subsequent following
delayed allocation write to the "hole", this would reclaim the same data
blocks again and results in fs corruption.

  # assmuing 4k block size ext4, with delalloc enabled
  # skip the first block and write to the second block
  xfs_io -fc "pwrite 4k 4k" -c "fsync" /mnt/ext4/testfile

  # converting to indirect-mapped file, which would move the data blocks
  # to the beginning of the file, but extent status cache still marks
  # that region as a hole
  chattr -e /mnt/ext4/testfile

  # delayed allocation writes to the "hole", reclaim the same data block
  # again, results in i_blocks corruption
  xfs_io -c "pwrite 0 4k" /mnt/ext4/testfile
  umount /mnt/ext4
  e2fsck -nf /dev/sda6
  ...
  Inode 53, i_blocks is 16, should be 8.  Fix? no
  ...

Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
fs/ext4/migrate.c