From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Allison Subject: Re: What trigge fsync of file on last close of the open inode? Date: Tue, 3 Oct 2006 16:13:18 -0700 Message-ID: <20061003231318.GP16692@linux> References: <4522BFA8.9040000@us.ibm.com> <1159905941.18918.7.camel@kleikamp.austin.ibm.com> <4522CBFD.3010202@us.ibm.com> Reply-To: Jeremy Allison Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Dave Kleikamp , linux-fsdevel@vger.kernel.org, Shirish S Pargaonkar Return-path: Received: from dp.samba.org ([66.70.73.150]:55467 "EHLO lists.samba.org") by vger.kernel.org with ESMTP id S1030663AbWJCXNV (ORCPT ); Tue, 3 Oct 2006 19:13:21 -0400 To: Steve French Content-Disposition: inline In-Reply-To: <4522CBFD.3010202@us.ibm.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue, Oct 03, 2006 at 03:45:49PM -0500, 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). > >> > > > >This is normal behavior for most file systems. I thought cifs protected > >this by flushing dirty data in cifs_close. I don't think any data > >should be dirtied after cifs_close is called (on the last open file > >handle). > > > I found it ... > > cifs exports flush, filp_close calls flush (before calling close) > > cifs_flush calls filemap_fdatawrite > > 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)? Steve, Here's a comment I found in the NFSv4 code.... might be relevent. >>From /usr/src/linux/fs/nfs/nfs4proc.c /* * It is possible for data to be read/written from a mem-mapped file * after the sys_close call (which hits the vfs layer as a flush). * This means that we can't safely call nfsv4 close on a file until * the inode is cleared.