Re: donor file data inconsistent after EXT4_IOC_MOVE_EXT

[Akira Fujita <a-fujita@rs.jp.nec.com>]

Hi Peng,

This is a known issue, and I sent a patch to linux-ext4 2 weeks ago.
Unfortunately it is not included in the ext4 patch queue yet.

http://marc.info/?l=linux-ext4&m=125447192709338&w=2

Would you retry your test case with above my patch?

Regards,
Akira Fujita

Peng Tao wrote:
> Hi,
> 
> As I am looking more closely to the EXT4_IOC_MOVE_EXT ioctl, I found a
> problem. The iotcl exchanges the block layout of the orig file and donor file
> and then writes out orig file data to orig file's new blocks.
> After the ioctl, the donor file would have the blocks previously owned by the
> orig file. But it turns out inconsistent.
> 
> A simple test case for revealing the bug:
> The program a.out is calling EXT4_IOC_MOVE_EXT against argv[1] (as orig file)
> and argv[2] (as donor file) and move_data.len = argv[1]'s block count.
> 
> And I am running mainline kernel 2.6.32-rc3 and the ext4 partition is mounted
> in ordered mode with default settings, if you are interested.
> 
> [bergwolf@move_extent]$sh test-5.sh 
> make full-img
> ========create full.img========
> dd if=/home/bergwolf/vm/OpenSolaris200805.iso of=full-1.img bs=1M count=30
> 30+0 records in
> 30+0 records out
> 31457280 bytes (31 MB) copied, 0.0847457 s, 371 MB/s
> dd if="/home/bergwolf/vm/WINXP_EN_PRO_SP3_MSDN/WinXp+Sp3 enu.iso" of=full-2.img bs=1M count=30
> 30+0 records in
> 30+0 records out
> 31457280 bytes (31 MB) copied, 0.0664263 s, 474 MB/s
> md5sum full-1.img full-2.img
> 4f47bee75290d094c94f8a7cb2075c69  full-1.img
> 9e35330146a610d0aa2fab1d16aa2b09  full-2.img
> ./a.out full-1.img full-2.img
> md5sum full-1.img full-2.img
> 4f47bee75290d094c94f8a7cb2075c69  full-1.img
> 9e35330146a610d0aa2fab1d16aa2b09  full-2.img		<---- wrong content
> [bergwolf@move_extent]$cd
> [bergwolf@~]$sudo umount /other/
> [bergwolf@~]$sudo mount /other/
> [bergwolf@~]$cd -
> /other/test/move_extent
> [bergwolf@move_extent]$md5sum full-1.img full-2.img 
> 4f47bee75290d094c94f8a7cb2075c69  full-1.img
> 4f47bee75290d094c94f8a7cb2075c69  full-2.img		<---- right result
> 
> I verified that the bug is because of the pagecache hit in the  vfs_read(), 
> via the following test case:
> 
> [bergwolf@move_extent]$sudo sh test-4.sh 
> make full-img
> ========create full.img========
> dd if=/home/bergwolf/vm/OpenSolaris200805.iso of=full-1.img bs=1M count=30
> 30+0 records in
> 30+0 records out
> 31457280 bytes (31 MB) copied, 0.115624 s, 272 MB/s
> dd if="/home/bergwolf/vm/WINXP_EN_PRO_SP3_MSDN/WinXp+Sp3 enu.iso" of=full-2.img bs=1M count=30
> 30+0 records in
> 30+0 records out
> 31457280 bytes (31 MB) copied, 1.16482 s, 27.0 MB/s
> md5sum full-1.img full-2.img
> 4f47bee75290d094c94f8a7cb2075c69  full-1.img
> 9e35330146a610d0aa2fab1d16aa2b09  full-2.img
> sync
> echo 1 > /proc/sys/vm/drop_caches	<------- this drops all pagecaches, FYI
> ./a.out full-1.img full-2.img
> md5sum full-1.img full-2.img
> 4f47bee75290d094c94f8a7cb2075c69  full-1.img
> 4f47bee75290d094c94f8a7cb2075c69  full-2.img
> 
> IIUC, this is because pagecache not uptodate.  FWIW, EXT4_IOC_MOVE_EXT
> calls ext4_ext_invalidate_cache() to prevent later access to donor file reading
> old data. But if the data is already in the pagecache (in which case,
> ext4_get_blocks() won't be called), vfs_read will still read the old data.
> But I don't know if there is a way to discard all pagecache for a specific
> inode. I tried to write something similar to ext4_da_block_invalidatepages()
> and ClearPageUptodate() on each page found in the mapping address,
> but it didn't work.
> 
> So am I missing anything? And any hints how to force the following vfs_read()
> to read from disk?
>