| commit | 7a3f595cc8298df14a7c71b0d876bafd8e9e1cbf | |
| author | Eric Sandeen <sandeen@redhat.com> | |
| Tue, 18 Dec 2007 00:20:10 +0000 (17 16:20 -0800) | ||
| committer | Linus Torvalds <torvalds@woody.linux-foundation.org> | |
| Tue, 18 Dec 2007 03:28:17 +0000 (17 19:28 -0800) | ||
| tree | e2409b01431e230369182d3a450dcd9c2c6beb0a | treesnapshot (tar.gz zip) |
| parent | 8998979cc1f90da5a48b2e8a13833217c63f7c4a | commitdiff |
ecryptfs: fix fsx data corruption problems
ecryptfs in 2.6.24-rc3 wasn't surviving fsx for me at all, dying after 4
ops. Generally, encountering problems with stale data and improperly
zeroed pages. An extending truncate + write for example would expose stale
data.
With the changes below I got to a million ops and beyond with all mmap ops
disabled - mmap still needs work. (A version of this patch on a RHEL5
kernel ran for over 110 million fsx ops)
I added a few comments as well, to the best of my understanding
as I read through the code.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Acked-by: Michael Halcrow <mhalcrow@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
ecryptfs in 2.6.24-rc3 wasn't surviving fsx for me at all, dying after 4
ops. Generally, encountering problems with stale data and improperly
zeroed pages. An extending truncate + write for example would expose stale
data.
With the changes below I got to a million ops and beyond with all mmap ops
disabled - mmap still needs work. (A version of this patch on a RHEL5
kernel ran for over 110 million fsx ops)
I added a few comments as well, to the best of my understanding
as I read through the code.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Acked-by: Michael Halcrow <mhalcrow@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| fs/ecryptfs/mmap.c | diffblobblamehistory | |
| fs/ecryptfs/read_write.c | diffblobblamehistory |