From: Josh MacDonald <jmacd@CS.Berkeley.EDU>
To: Rik van Riel <riel@conectiva.com.br>
Cc: Hans Reiser <reiser@namesys.com>, Chris Mason <mason@suse.com>,
Andreas Dilger <adilger@turbolabs.com>,
Shawn Starr <spstarr@sh0n.net>,
linux-kernel@vger.kernel.org, ext2-devel@lists.sourceforge.net
Subject: Re: Possible Idea with filesystem buffering.
Date: Wed, 23 Jan 2002 09:15:23 -0800 [thread overview]
Message-ID: <20020123091522.A16614@helen.CS.Berkeley.EDU> (raw)
In-Reply-To: <3C4DB36F.4090306@namesys.com> <Pine.LNX.4.33L.0201221818140.32617-100000@imladris.surriel.com>
In-Reply-To: <Pine.LNX.4.33L.0201221818140.32617-100000@imladris.surriel.com>; from riel@conectiva.com.br on Tue, Jan 22, 2002 at 06:20:52PM -0200
Quoting Rik van Riel (riel@conectiva.com.br):
> On Tue, 22 Jan 2002, Hans Reiser wrote:
> > Rik van Riel wrote:
> > >On Tue, 22 Jan 2002, Chris Mason wrote:
>
> > >>The FS doesn't know how long a page has been dirty, or how often it
> > >>gets used,
> > >
> > >In an efficient system, the FS will never get to know this, either.
> >
> > I don't understand this statement. If dereferencing a vfs op for
> > every page aging is too expensive, then ask it to age more than one
> > page at a time. Or do I miss your meaning?
>
> Please repeat after me:
>
> "THE FS DOES NOT SEE THE MMU ACCESSED BITS"
>
> Also, if a piece of data is in the page cache, it is accessed
> without calling the filesystem code.
>
>
> This means the filesystem doesn't know how often pages are or
> are not used, hence it cannot make the decisions the VM make.
>
> Or do you want to have your own ReiserVM and ReiserPageCache ?
Rik,
We think there are good reasons for the FS to know when and how
its data is accessed, although this issue is less significant than
the semantics of writepage() being discussed in this thread.
Referring to the transaction design document I posted several months
ago:
http://marc.theaimsgroup.com/?l=linux-kernel&m=100510090926874&w=2
Our intention is for the file system to be capable of tracking
read and write data-dependencies so that it can safely defer
writing batches of data and still guarantee consistent crash
recovery from the application's point of view. The interaction
between transactions and mmaped regions may leave something to
be desired, and we may not need to know how often pages are or
are not used, but we would like to know which pages are read and
written by whom, even for the case of a page cache hit.
-josh
--
PRCS version control system http://sourceforge.net/projects/prcs
Xdelta storage & transport http://sourceforge.net/projects/xdelta
Need a concurrent skip list? http://sourceforge.net/projects/skiplist
next prev parent reply other threads:[~2002-01-23 17:18 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-20 9:04 Shawn
2002-01-20 11:31 ` Hans Reiser
2002-01-20 13:56 ` Rik van Riel
2002-01-20 14:21 ` Hans Reiser
2002-01-20 15:13 ` Rik van Riel
2002-01-20 21:15 ` Hans Reiser
2002-01-20 21:24 ` Rik van Riel
2002-01-20 21:30 ` Hans Reiser
2002-01-20 21:40 ` Rik van Riel
2002-01-20 21:49 ` Hans Reiser
2002-01-20 22:00 ` Rik van Riel
2002-01-21 0:10 ` Matt
2002-01-21 0:57 ` Hans Reiser
2002-01-21 1:28 ` Anton Altaparmakov
2002-01-21 2:29 ` Shawn Starr
2002-01-21 19:15 ` Shawn Starr
2002-01-22 22:02 ` Hans Reiser
2002-01-21 9:21 ` Horst von Brand
2002-01-21 9:13 ` Horst von Brand
2002-01-21 15:29 ` Eric W. Biederman
2002-01-20 17:51 ` Mark Hahn
2002-01-20 21:24 ` Hans Reiser
2002-01-20 21:32 ` Rik van Riel
2002-01-21 15:37 ` Eric W. Biederman
2002-01-20 22:45 ` Shawn Starr
2002-01-20 23:11 ` Rik van Riel
2002-01-20 23:40 ` Shawn Starr
2002-01-20 23:48 ` Rik van Riel
2002-01-21 0:44 ` Hans Reiser
2002-01-21 0:52 ` Rik van Riel
2002-01-21 1:08 ` Hans Reiser
2002-01-21 1:39 ` Rik van Riel
2002-01-21 11:10 ` Hans Reiser
2002-01-21 12:12 ` Rik van Riel
2002-01-21 13:42 ` Hans Reiser
2002-01-21 13:54 ` Rik van Riel
2002-01-21 14:07 ` Hans Reiser
2002-01-21 17:21 ` Chris Mason
2002-01-21 17:47 ` Hans Reiser
2002-01-21 19:44 ` Chris Mason
2002-01-21 20:41 ` Hans Reiser
2002-01-21 21:53 ` Chris Mason
2002-01-22 6:02 ` Andreas Dilger
2002-01-22 10:09 ` Tommi Kyntola
2002-01-22 11:39 ` Hans Reiser
2002-01-22 18:41 ` Andrew Morton
2002-01-22 19:03 ` Rik van Riel
2002-01-23 20:35 ` [Ext2-devel] " Stephen C. Tweedie
2002-01-23 20:48 ` Hans Reiser
2002-01-23 20:55 ` Andrew Morton
2002-01-23 23:53 ` Hugh Dickins
2002-01-24 0:01 ` Jeff Garzik
2002-01-22 20:19 ` Hans Reiser
2002-01-22 20:50 ` Rik van Riel
2002-01-22 14:03 ` Chris Mason
2002-01-22 14:39 ` Rik van Riel
2002-01-22 18:46 ` Hans Reiser
2002-01-22 20:13 ` Steve Lord
2002-01-22 20:20 ` Rik van Riel
2002-01-22 22:31 ` Hans Reiser
2002-01-22 23:34 ` Rik van Riel
2002-01-23 17:15 ` Josh MacDonald [this message]
2002-01-22 19:19 ` Chris Mason
2002-01-22 20:32 ` Hans Reiser
2002-01-22 21:12 ` Rik van Riel
2002-01-22 21:28 ` Shawn Starr
2002-01-22 21:31 ` Rik van Riel
2002-01-22 21:08 ` Chris Mason
2002-01-22 22:05 ` Hans Reiser
2002-01-22 22:21 ` Rik van Riel
2002-01-23 0:16 ` Hans Reiser
2002-01-22 22:10 ` Richard B. Johnson
2002-01-23 1:14 ` Stuart Young
2002-01-23 17:16 ` Daniel Phillips
2002-01-22 21:22 ` Chris Mason
2002-01-21 0:28 ` Hans Reiser
2002-01-21 0:47 ` Rik van Riel
2002-01-21 1:01 ` Hans Reiser
2002-01-21 1:21 ` Rik van Riel
2002-01-21 1:26 ` Hans Reiser
2002-01-21 1:40 ` Rik van Riel
2002-01-20 15:49 ` Anton Altaparmakov
2002-01-20 21:21 ` Hans Reiser
2002-01-22 21:02 Rolf Lear
[not found] <Pine.LNX.4.33L.0201222008280.32617-100000@imladris.surriel.com>
2002-01-22 23:31 ` Shawn Starr
2002-01-22 23:37 ` Rik van Riel
2002-01-23 5:26 ` Shawn Starr
2002-01-23 9:43 Martin Knoblauch
2002-01-23 11:52 ` Helge Hafting
2002-01-23 12:02 ` Rik van Riel
2002-01-23 12:11 ` Martin Knoblauch
[not found] <Pine.LNX.4.33.0201231301560.24338-100000@coffee.psychology.mcmaster.ca>
[not found] ` <3C4FC478.BCC44CDF@TeraPort.de>
[not found] ` <3C4FDB80.C9F83EBB@aitel.hist.no>
2002-01-24 13:59 ` Martin Knoblauch
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=20020123091522.A16614@helen.CS.Berkeley.EDU \
--to=jmacd@cs.berkeley.edu \
--cc=adilger@turbolabs.com \
--cc=ext2-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mason@suse.com \
--cc=reiser@namesys.com \
--cc=riel@conectiva.com.br \
--cc=spstarr@sh0n.net \
/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
Powered by JetHome