lkml.org 
[lkml]   [2003]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: 2.6 must-fix list, v2
From
>>>>> " " == 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/

\
 
 \ /
  Last update: 2005-03-22 13:35    [W:0.078 / U:0.728 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site