> (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/