Messages in this thread | | | Date | Tue, 13 May 2003 18:27:35 +0200 | Subject | Re: 2.6 must-fix list, v2 | From | Trond Myklebust <> |
| |
>>>>> " " == Dave Jones <davej@codemonkey.org.uk> writes:
> (16:30:08:root@tetrachloride:mesh)# ~/fsx voon truncating to > largest ever: 0x13e76 truncating to largest ever: 0x2e52c > truncating to largest ever: 0x3c2c2 truncating to largest ever: > 0x3f15f truncating to largest ever: 0x3fcb9 truncating to > largest ever: 0x3fe96 truncating to largest ever: 0x3ff9d Size > error: expected 0x2126e stat 0x21546 seek 0x21546 LOG DUMP > (7665 total operations): 7666(242 mod 256): READ 0x1b20b thru > 0x215b7 (0x63ad bytes) 7667(243 mod 256): MAPWRITE 0x247ef thru > 0x26e9f (0x26b1 bytes) 7668(244 mod 256): WRITE 0x26fc thru > 0x11d2f (0xf634 bytes) 7669(245 mod 256): TRUNCATE DOWN from > 0x3b18c to 0x1cbfc 7670(246 mod 256): MAPREAD 0x7f92 thru > 0xd860 (0x58cf byte .... etc...
Ah... mmap()ed writes + truncate()...
OK. There's currently a known problem here which appears both in 2.4.x and 2.5.x: we appear to be incapable of flushing out all the dirty pages prior to truncating the file. The usual filemap_fdatasync()/filemap_fdatawait() appears to be subject to races with VM swapping.
Could we have some help from the VM experts on this one?
Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |