[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <5321F226.80505@fr.ibm.com>
Date: Thu, 13 Mar 2014 19:00:06 +0100
From: Cedric Le Goater <clg@...ibm.com>
To: "Theodore Ts'o" <tytso@....edu>
CC: Andreas Dilger <adilger.kernel@...ger.ca>, Jan Kara <jack@...e.cz>,
linux-ext4@...r.kernel.org, anton@...ba.org
Subject: ext4 extent issue when page size > block size
Hi,
While running openldap unit tests on a ppc64 system, we have had
issues with the cp command. cp uses the FS_IOC_FIEMAP ioctl to
optimize the copy and it appeared that the ext4 extent list of
the file did not match all the data which was 'written' on disk.
The system we use has a 64kB page size but the page size being
greater than the filesystem block seems to be the top level reason
of the problem. One can use a 1kB block size filesystem to reproduce
the issue on a 4kB page size system.
Attached is a simple test case from Anton, which creates extents
as follow :
lseek(48K -1) -> creates [11/1)
p = mmap(128K)
*(p) = 1 -> creates [0/1) with a fault
lseek(128K) -> creates [31/1)
*(p + 49K) = 1 -> creates [12/1) and then merges in [11/2)
munmap(128K)
On a 4kB page size system, the extent list returned by FS_IOC_FIEMAP
looks correct :
Extent 0: logical: 0 physical: 0 length: 4096 flags 0x006
Extent 1: logical: 45056 physical: 0 length: 8192 flags 0x006
Extent 2: logical: 126976 physical: 0 length: 4096 flags 0x007
But, with a 64kB page size, we miss the in-the-middle extent (no page
fault but the data is on disk) :
Extent 0: logical: 0 physical: 0 length: 49152 flags 0x006
Extent 1: logical: 126976 physical: 0 length: 4096 flags 0x007
This looks wrong. Right ? Or are we doing something wrong ? I have been
digging in the ext4 page writeback code. There are some caveats when
blocksize < pagesize but I am not sure my understanding is correct.
Many thanks,
C.
View attachment "mmap_lseek_issue0.c" of type "text/plain" (2560 bytes)
Powered by blists - more mailing lists