From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve French Subject: Re: writethrough of mmapped pages Date: Sat, 31 Jan 2004 18:16:45 -0600 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <401C456D.3050709@austin.rr.com> References: <401C371B.6020909@austin.rr.com> <401C3E2D.7040806@austin.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org, linux-cifs-client@lists.samba.org Return-path: Received: from ms-smtp-01.texas.rr.com ([24.93.47.40]:19600 "EHLO ms-smtp-01-eri0.texas.rr.com") by vger.kernel.org with ESMTP id S264437AbUBAAQw (ORCPT ); Sat, 31 Jan 2004 19:16:52 -0500 To: unlisted-recipients:; (no To-header on input) List-Id: linux-fsdevel.vger.kernel.org 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). >