Bug 22452
| Summary: | data corruption after mmap()ing a file and writev() some data to another file | ||
|---|---|---|---|
| Product: | File System | Reporter: | Marius Tolzmann (marius) |
| Component: | XFS | Assignee: | XFS Guru (xfs-masters) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | high | CC: | florian, hch, maciej.rutecki, rjw, wizarddewhite, wwwutz |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.36 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 16444 | ||
| Attachments: |
map-test.c mmap() a file and writev() back to another file
Handle delalloc truncation during failed writes without xfs_setattr map-test.c mmap() a file and writev() back to another file gplv2+ version: map-test.c mmap() a file and writev() back to another file wtfpl version: map-test.c mmap() a file and writev() back to another file |
||
Verified. Ext2 shows the same problems so it seems like a generic problem with the new truncate sequence. Created attachment 36842 [details]
Handle delalloc truncation during failed writes without xfs_setattr
This is a patch that fixes your testcase by not using xfs_setattr for truncating delalloc blocks on a failed write, but rather doing it manually. It does pass xfstests for me, but probably isn't the final version yet. I'll move additional discussion on it to the mailinglist.
Btw, can you license your testcase under GPLv2 or any less restrictive license? We'd like to include it in the xfstests regression test suite.
Created attachment 36892 [details]
map-test.c mmap() a file and writev() back to another file
now including the gpl header to make it possible to include it in the xfstests regression test suite. 8)
regards,
marius tolzmann
thanks for fixing it.. since ext2 seems to show a similar problem how is the "normal" way to somehow clone this bug or refile it to their list? - we don't use ext[234] here so i can't run the testcase on ext2. Any chance you could relicense it under GPLv2/GPLVv2+ or similar? The GPLv3 is unfortunately more restrictive than the rest of xfstests. (In reply to comment #4) > since ext2 seems to show a similar problem how is the "normal" way to somehow > clone this bug or refile it to their list? - we don't use ext[234] here so i > can't run the testcase on ext2. Sorry, ext2 isn't affected in the end, I just tested the wrong partition. The only other likely suspect, gfs2 doesn't seem to be affected either. Created attachment 36932 [details]
gplv2+ version: map-test.c mmap() a file and writev() back to another file
so now GPLv2+.. ;)
Created attachment 36942 [details]
wtfpl version: map-test.c mmap() a file and writev() back to another file
alternativly licensed it under the WTFPL ;)
Fixed by commit c726de4 xfs: fix failed write truncation handling. |
Created attachment 36732 [details] map-test.c mmap() a file and writev() back to another file Hi there, we experienced some serious database corruptions in cyrus imap after switching to the latest stable kernel (2.6.36). we traced this down to some mmap()ing and writev() afterwards. Donald Buczek wrote a small test-program to reproduce this (.c-file attached) to reproduce the corruption please compile map-test.c and run: echo -n "cccccccccc">test.flat ./map-test xxd test.flat.NEW how we built the xfs and mounted it: mkfs.xfs /dev/sda3 mount /dev/sda3 /mnt example output under XFS: (/dev/sda3 /mnt xfs rw,relatime,attr2,noquota) 0000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000010: 0000 0000 6363 6363 6363 6363 6363 ....cccccccccc example output under reiserfs: 0000000: 6161 6161 6161 6161 6161 6262 6262 6262 aaaaaaaaaabbbbbb 0000010: 6262 6262 6363 6363 6363 6363 6363 bbbbcccccccccc please let me know what else to provide to make reproducing this bug easier.. we downgraded to linux 2.6.35.8 and everything seems to be fine again. regards, marius tolzmann