linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Whitehouse <swhiteho@redhat.com>
To: Zach Brown <zab@redhat.com>, Abhijith Das <adas@redhat.com>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	cluster-devel <cluster-devel@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC] readdirplus implementations: xgetdents vs dirreadahead syscalls
Date: Fri, 25 Jul 2014 19:08:12 +0100	[thread overview]
Message-ID: <53D29D0C.2040606@redhat.com> (raw)
In-Reply-To: <20140725175257.GK17798@lenny.home.zabbo.net>

Hi,

On 25/07/14 18:52, Zach Brown wrote:
> On Fri, Jul 25, 2014 at 01:37:19PM -0400, Abhijith Das wrote:
>> Hi all,
>>
>> The topic of a readdirplus-like syscall had come up for discussion at last year's
>> LSF/MM collab summit. I wrote a couple of syscalls with their GFS2 implementations
>> to get at a directory's entries as well as stat() info on the individual inodes.
>> I'm presenting these patches and some early test results on a single-node GFS2
>> filesystem.
>>
>> 1. dirreadahead() - This patchset is very simple compared to the xgetdents() system
>> call below and scales very well for large directories in GFS2. dirreadahead() is
>> designed to be called prior to getdents+stat operations.
> Hmm.  Have you tried plumbing these read-ahead calls in under the normal
> getdents() syscalls?
>
> We don't have a filereadahead() syscall and yet we somehow manage to
> implement buffered file data read-ahead :).
>
> - z
>
Well I'm not sure thats entirely true... we have readahead() and we also 
have fadvise(FADV_WILLNEED) for that. It could be added to getdents() no 
doubt, but how would we tell getdents64() when we were going to read the 
inodes, rather than just the file names? We may only want to readahead 
some subset of the directory entries rather than all of them, so the 
thought was to allow that flexibility by making it, its own syscall,

Steve.

  reply	other threads:[~2014-07-25 18:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1106785262.13440918.1406308542921.JavaMail.zimbra@redhat.com>
2014-07-25 17:37 ` [RFC] readdirplus implementations: xgetdents vs dirreadahead syscalls Abhijith Das
2014-07-25 17:52   ` Zach Brown
2014-07-25 18:08     ` Steven Whitehouse [this message]
2014-07-25 18:28       ` [Cluster-devel] " Zach Brown
2014-07-25 20:02         ` Steven Whitehouse
2014-07-25 20:30           ` Trond Myklebust
2014-07-26  0:38     ` Dave Chinner
2014-07-28 12:22       ` Abhijith Das
2014-07-28 14:30         ` Zuckerman, Boris
2014-07-31  3:25         ` Dave Chinner
2014-07-28 21:21       ` Andreas Dilger
2014-07-31  3:16         ` Dave Chinner

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=53D29D0C.2040606@redhat.com \
    --to=swhiteho@redhat.com \
    --cc=adas@redhat.com \
    --cc=cluster-devel@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zab@redhat.com \
    /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).