public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jesse Pollard <pollard@admin.navo.hpc.mil>
To: jw schultz <jw@pegasys.ws>, linux-kernel@vger.kernel.org
Subject: Re: Heuristic readahead for filesystems
Date: Thu, 12 Sep 2002 07:41:28 -0500	[thread overview]
Message-ID: <200209120741.28278.pollard@admin.navo.hpc.mil> (raw)
In-Reply-To: <20020912004520.GD10315@pegasys.ws>

On Wednesday 11 September 2002 07:45 pm, jw schultz wrote:
> On Wed, Sep 11, 2002 at 03:21:37PM -0400, Richard B. Johnson wrote:
> > On Wed, 11 Sep 2002, Oliver Neukum wrote:
> > > Am Mittwoch, 11. September 2002 20:43 schrieb Xuan Baldauf:
> > > > > Aio should be able to do it. But even that want help you with the
> > > > > stat data.
> > > >
> > > > Aio would help me announcing stat() usage for the future?
> > >
> > > No, it won't. But it would solve the issue of reading ahead.
> > > Stating needs a kernel implementation of 'stat ahead'
> > > -
> >
> > I think this is discussed in the future. Write-ahead is the
> > next problem solved. ?;)
>
> Gating back to the original issue which was "readahead" of
> stat() info...
>
> The userland open of a directory could trigger an advance
> reading of the directory data and of the inode structs of
> all it's immediate members.  Almost all instances of a
> usermode open on a directory will be doing fstats.  Even a
> command line ls often has options (colour, -F, etc) turned on
> by default that require fstat on all the entries.
> The question would be how far ahead of the user app would
> the kernel be.
>
> I could possibly see having a fcntl() for directories to
> pre-read just the first block of each file to accelerate
> file-managers that use magic and perhaps forestall readahead
> pulling in more than magic will use.

The problem now is that this becomes filesystem dependant.
Some of the filesystems will already have the inode loaded, and
if the inode is loaded, then the first block of the file is also loaded.

If the proposed readahead is done at the VFS level then multiple
reads will be issued for the same block, with some physical IO
reduction done due to cache hits.

This is starting to sound like a bit of overoptimization.

Still.. Try it. and on different filesystems and see what happens.

-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

  parent reply	other threads:[~2002-09-12 12:37 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-11 15:42 Heuristic readahead for filesystems Xuan Baldauf
2002-09-11 16:33 ` Davide Libenzi
2002-09-11 17:03   ` jdow
2002-09-11 17:20     ` Davide Libenzi
2002-09-11 17:51       ` jdow
2002-09-11 17:16   ` Hans Reiser
2002-09-11 16:42 ` Rik van Riel
2002-09-11 17:20   ` Oliver Neukum
2002-09-11 17:56   ` Xuan Baldauf
2002-09-11 18:30     ` Oliver Neukum
2002-09-11 18:43       ` Xuan Baldauf
2002-09-11 19:04         ` Oliver Neukum
2002-09-11 19:21           ` Richard B. Johnson
2002-09-12  0:45             ` jw schultz
2002-09-12  1:58               ` Andrew Morton
2002-09-12 11:41               ` Richard B. Johnson
2002-09-12 13:35                 ` jw schultz
2002-09-12 21:33                 ` jdow
2002-09-16 12:52                   ` Richard B. Johnson
2002-09-17  1:45                     ` jdow
2002-09-17 10:37                       ` jbradford
2002-09-17  5:19                     ` jdow
2002-09-12 12:41               ` Jesse Pollard [this message]
2002-09-11 19:03   ` Tomas Szepe

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=200209120741.28278.pollard@admin.navo.hpc.mil \
    --to=pollard@admin.navo.hpc.mil \
    --cc=jw@pegasys.ws \
    --cc=linux-kernel@vger.kernel.org \
    /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