From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zach Brown Subject: Re: What trigge fsync of file on last close of the open inode? Date: Tue, 03 Oct 2006 14:15:58 -0700 Message-ID: <4522D30E.7080505@oracle.com> References: <4522BFA8.9040000@us.ibm.com> <1159905941.18918.7.camel@kleikamp.austin.ibm.com> <4522CBFD.3010202@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Dave Kleikamp , linux-fsdevel@vger.kernel.org, Shirish S Pargaonkar Return-path: Received: from tetsuo.zabbo.net ([207.173.201.20]:8589 "EHLO tetsuo.zabbo.net") by vger.kernel.org with ESMTP id S1030451AbWJCVQA (ORCPT ); Tue, 3 Oct 2006 17:16:00 -0400 To: Steve French In-Reply-To: <4522CBFD.3010202@us.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Steve French wrote: > Dave Kleikamp wrote: >>> Someone had reported a problem with a writepages call coming in on >>> with no open files (so presumably the file was closed, with dirty >>> pages not written). So is the problem that you're getting a cifs_writepages() call after cifs_close() returns? fwiw, 9 out of 10 brains would be less confused if cifs_close() was called cifs_release(). > May be a case in which filemap_fdatawrite returns before the write(s) is > sent to the vfs and write races with close (although cifs will defer a > file close if a write is pending on that handle)? Are writes to mmap()ed regions involved at all? They lead to pages being dirtied at unmapping and eventually hitting ->writepage, potentially after ->flush and ->release have been called. I imagine you could force writeback of dirty pages in ->release so that you don't wait for writeback to come around and hit them. Heck, it might be doing this already. I didn't look very hard :). - z