public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Peng Tao <bergwolf@gmail.com>
To: ext4 development <linux-ext4@vger.kernel.org>
Cc: Akira Fujita <a-fujita@rs.jp.nec.com>,
	Kazuya Mio <k-mio@sx.jp.nec.com>, Theodore Ts'o <tytso@mit.edu>
Subject: donor file data inconsistent after EXT4_IOC_MOVE_EXT
Date: Sun, 18 Oct 2009 15:03:14 +0800	[thread overview]
Message-ID: <4ADABDB2.6080905@gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 3407 bytes --]

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?

-- 
Best Regards,
Peng Tao
State Key Laboratory of Networking and Switching Technology
Beijing Univ. of Posts and Telecoms.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

             reply	other threads:[~2009-10-18  7:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-18  7:03 Peng Tao [this message]
2009-10-19  0:40 ` donor file data inconsistent after EXT4_IOC_MOVE_EXT Akira Fujita
2009-10-19  2:28   ` Peng Tao
2009-10-19  5:42     ` Peng Tao
2009-10-19  8:28       ` Akira Fujita

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ADABDB2.6080905@gmail.com \
    --to=bergwolf@gmail.com \
    --cc=a-fujita@rs.jp.nec.com \
    --cc=k-mio@sx.jp.nec.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox