[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-fsdevel
Subject:    Re: writethrough of mmapped pages
From:       Steve French <smfrench () austin ! rr ! com>
Date:       2004-02-01 0:16:45
Message-ID: 401C456D.3050709 () austin ! rr ! com
[Download RAW message or body]

Well the filemap_fdatawrite after generic_write seems to cause the 
problem. Removing the call to it there worked around the problem - fsx 
works fine as long as I don't flush the dirty data with 
filemap_fdatawrite after the call to generic_write in my write wrapper 
routine. Removing it fixed the problem (but that doesn't seem to be very 
useful since when I lose the caching token - I really do need to flush 
the data to the server after every write - and if filemap_fdatawrite is 
not safe to call after every write - what routine should I call?)

Steve French wrote:

> The experiment described at the bottom (always calling the generic 
> read and write but doing filemap_fdatasync and invalidate_remote_inode 
> when file not cacheable) failed - same symptom. It looks like the 
> portion of page implicitly extended is not zeroed properly but I am 
> not sure why calling filemap_fdatasync early would make a difference. 
> In the note below there is a typo - I meant invalidate_remote_inode 
> not invalidate_inode_pages (since when the file is not cacheable I 
> have to force the client to reread the pages).
>

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]