From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Layton Subject: Re: set last write time = fsync ? Date: Fri, 14 Mar 2008 19:19:08 -0400 Message-ID: <20080314191908.32572398@tleilax.poochiereds.net> References: <524f69650803122054t7b0f8285kd564271f8340378e@mail.gmail.com> <20080313071046.1a9350a9@tleilax.poochiereds.net> <524f69650803131932w91fa962i261a4c72a99db9d8@mail.gmail.com> <20080314064017.6aa3e471@tleilax.poochiereds.net> <524f69650803140916w1dde16a9ja9dc4e052edd77e5@mail.gmail.com> <20080314125526.002fc2e5@tleilax.poochiereds.net> <524f69650803141219w53704411te1076358dd964a2f@mail.gmail.com> <20080314163557.0dac9896@tleilax.poochiereds.net> <524f69650803141438t4deba0adk15a9b4e3d25f24fb@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: linux-cifs-client@lists.samba.org, "Guenter Kukkukk" , linux-fsdevel To: "Steve French" Return-path: Received: from mx1.redhat.com ([66.187.233.31]:36083 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751634AbYCNXTO (ORCPT ); Fri, 14 Mar 2008 19:19:14 -0400 In-Reply-To: <524f69650803141438t4deba0adk15a9b4e3d25f24fb@mail.gmail.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, 14 Mar 2008 16:38:27 -0500 "Steve French" wrote: > On Fri, Mar 14, 2008 at 3:35 PM, Jeff Layton wrote: > > On Fri, 14 Mar 2008 14:19:06 -0500 > > > > "Steve French" wrote: > > > > > On Fri, Mar 14, 2008 at 11:55 AM, Jeff Layton wrote: > > > > On Fri, 14 Mar 2008 11:16:41 -0500 > > > > > > > > "Steve French" wrote: > > > > > > > > > > > > > I don't worry about flushing atime (anyone crazy enough to do that > > > > > would pay a huge performance penalty). > > > > > Access is usually checked on open right ... so once a file is open > > > > > even if the file becomes read-only, the writes, even cached writes > > > > > continue. > > > > > > > > > > > > > Ahh, you're correct. I've been doing a lot of NFS work lately and was > > > > thinking stateless... :-) > > > > > > > > That patch should be OK then, though I think if someone is purposefully > > > > setting the atime we should take care not to clobber it. We're not > > > > going to be going through this codepath on every atime update, are we? > > > > Just on utimes() type calls, correct? If so, doing a flush on atime > > > > updates might be reasonable as well... > > > > > > > > Jeff Layton > > > > > > > > > > I don't think we need to flush before setting (just) atime. > > > If the problem with timestamps is delayed writes getting written out > > > on close ... won't close update the atime anyway? > > > > > > > > Consider that an app like tar might do something like this: > > > > open() > > write() > > write() > > write() > > close() > > utimes() > > > > The app would likely set the mtime too, but I'm not sure we should make > > that assumption. The question is -- should we allow that utimes() call > > to be clobbered by writes lingering around after the close() returns? > > There can't be writes lingering around after the close ... filp_close does > a flush before calling fput. > > Right, but we don't do filemap_fdatawait() on flush so I suppose we're not guaranteed to actually have all the writes out on the wire before the close occurs. IIRC, the current writepages implementation in cifs I think does effectively wait until all the writes have completed before returning, so a filemap_fdatawait wouldn't really do make any difference. Anyway, after looking back over the original problem, I think I'm convinced that your original patch is OK. ACK Thanks, -- Jeff Layton