From: Mark Fasheh <mark.fasheh@oracle.com>
To: Chris Wedgwood <cw@f00f.org>
Cc: Arjan van de Ven <arjan@linux.intel.com>,
Dave Kleikamp <shaggy@austin.ibm.com>,
Christoph Hellwig <hch@lst.de>,
Valerie Henson <val_henson@linux.intel.com>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Akkana Peck <akkana@shallowsky.com>,
Jesse Barnes <jesse.barnes@intel.com>,
jsipek@cs.sunysb.edu, Al Viro <viro@ftp.linux.org.uk>
Subject: Re: [RFC] [PATCH] Relative lazy atime
Date: Sat, 5 Aug 2006 15:22:47 -0700 [thread overview]
Message-ID: <20060805222247.GQ29686@ca-server1.us.oracle.com> (raw)
In-Reply-To: <20060805183609.GA7564@tuatara.stupidest.org>
On Sat, Aug 05, 2006 at 11:36:09AM -0700, Chris Wedgwood wrote:
> should it be atime-dirty or non-critical-dirty? (ie. make it more
> generic to cover cases where we might have other non-critical fields
> to flush if we can but can tolerate loss if we dont)
So, just to be sure - we're fine with atime being lost due to crashes,
errors, etc?
I don't see why not, but I figure it'd be good to make sure there's some
concensus on that.
If that is in fact the case, OCFS2 could do the same thing as XFS and
update disk only when we're going there for some other reason. The only
thing that we would have to add on top of that is a disk write when we're
dropping a cluster lock and the inode is still 'atime-dirty'.
--Mark
--
Mark Fasheh
Senior Software Developer, Oracle
mark.fasheh@oracle.com
next prev parent reply other threads:[~2006-08-05 22:27 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-03 6:36 [RFC] [PATCH] Relative lazy atime Valerie Henson
2006-08-03 14:48 ` Matthew Wilcox
2006-08-05 12:25 ` Christoph Hellwig
2006-08-05 13:22 ` Arjan van de Ven
2006-08-09 14:03 ` Valerie Henson
2006-08-09 15:49 ` Erez Zadok
2006-08-10 12:27 ` Helge Hafting
2006-08-05 16:58 ` Dave Kleikamp
2006-08-05 17:04 ` Arjan van de Ven
2006-08-05 18:36 ` Chris Wedgwood
2006-08-05 22:22 ` Mark Fasheh [this message]
2006-08-05 23:06 ` David Lang
2006-08-05 23:28 ` dean gaudet
2006-08-06 0:11 ` Chris Wedgwood
2006-08-06 3:01 ` Matthew Wilcox
2006-08-09 6:39 ` Valerie Henson
2006-08-09 12:21 ` Jörn Engel
2006-08-09 12:58 ` Dave Kleikamp
2006-08-10 11:34 ` Frank van Maarseveen
2006-08-10 17:28 ` Bill Davidsen
2006-08-06 0:13 ` Mark Fasheh
[not found] <6Gts4-6UM-1@gated-at.bofh.it>
[not found] ` <6GxFs-4Tg-13@gated-at.bofh.it>
[not found] ` <6Gy8r-5Oh-11@gated-at.bofh.it>
[not found] ` <6Gze7-7oP-7@gated-at.bofh.it>
[not found] ` <6GCOJ-4fv-19@gated-at.bofh.it>
[not found] ` <6GDB1-5qX-3@gated-at.bofh.it>
[not found] ` <6GDKT-5Eb-37@gated-at.bofh.it>
[not found] ` <6GHbD-2hm-1@gated-at.bofh.it>
[not found] ` <6HQ3c-6Pf-9@gated-at.bofh.it>
[not found] ` <6HVml-6DI-11@gated-at.bofh.it>
[not found] ` <6Ih3l-5FP-1@gated-at.bofh.it>
2006-08-10 13:07 ` Bodo Eggert
-- strict thread matches above, loose matches on Subject: below --
2006-08-03 6:29 Valerie Henson
2006-08-03 6:44 ` Josef Sipek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060805222247.GQ29686@ca-server1.us.oracle.com \
--to=mark.fasheh@oracle.com \
--cc=akkana@shallowsky.com \
--cc=arjan@linux.intel.com \
--cc=cw@f00f.org \
--cc=hch@lst.de \
--cc=jesse.barnes@intel.com \
--cc=jsipek@cs.sunysb.edu \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=shaggy@austin.ibm.com \
--cc=val_henson@linux.intel.com \
--cc=viro@ftp.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).