From: Martin Knoblauch <spamtrap-Ys4E+72pFW0hFhg+JK9F0w@public.gmane.org>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: linux-nfs list <linux-nfs@vger.kernel.org>
Subject: Re: RFC/Patch: Make NFS Readahead tunable
Date: Tue, 15 Apr 2008 09:40:35 -0700 (PDT) [thread overview]
Message-ID: <78295.47709.qm@web32602.mail.mud.yahoo.com> (raw)
----- Original Message ----
> From: Trond Myklebust <trond.myklebust@fys.uio.no>
> To: Martin Knoblauch <spamtrap-Ys4E+72pFW0hFhg+JK9F0w@public.gmane.org>
> Cc: linux-nfs list <linux-nfs@vger.kernel.org>
> Sent: Tuesday, April 15, 2008 6:12:32 PM
> Subject: Re: RFC/Patch: Make NFS Readahead tunable
>
>
> On Tue, 2008-04-15 at 06:39 -0700, Martin Knoblauch wrote:
> > Hi,
> >
> > while tracking down a very interesting interaction between Sun/SAM-FS and
> Linux NFS clients, we found out that the value of NFS_MAX_READ_AHEAD is to
> agressive/big for the specific use-case.
> >
> > For testing, instead of always recompiling the kernel with different values,
> I came up with the following patch. It introduces a tunable
> "/proc/sys/fs/nfs/nfs_ra_factor" with possible values between 0-15.
> >
> > Not sure whether it is actually a good thing to have. Better would be to set
> the read-ahead factor per filesystem via a mount option.
> >
> > The patch is against 2.6.24. It applies with offsets against 2.6.25-rc9. In
> case my mail client messes up the whitespace, the patch is also attached.
>
> NFS_MAX_READ_AHEAD just sets an upper limit on the standard vfs/mm-level
> page readahead algorithm. If you need finer control over that readahead
> algorithm, then the kernel already has full support for the
> posix_fadvise() system call.
>
But to use posix_fadvise I would need control over the application. Correct? This is not given in the case I am actually dealing with. The NFS-server is Solaris-10/Sparc/SAM-FS. It turns out that *any* access to an "offline" file from a Linux-NFS client messes (and I mean messes) up the performance of the stager process if the read-ahead window is larger that 2 or three time rsize. Now - I have a pretty clear opinion of "who is at fault", but doing a band-aid on the Linux side may just be the easier thing, at least short/mid-term. Not sure how important the end-customer really is to the makers of SAM-FS.
In general, of course controlling the readahead behaviour from the application is the better solution. anyway, the patch is simple enough to carry around.
Martin
> Cheers
> Trond
>
>
>
next reply other threads:[~2008-04-15 16:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-15 16:40 Martin Knoblauch [this message]
-- strict thread matches above, loose matches on Subject: below --
2008-04-15 13:39 RFC/Patch: Make NFS Readahead tunable Martin Knoblauch
[not found] ` <975253.58176.qm-f6uctMgKLEavuULXzWHTWIglqE1Y4D90QQ4Iyu8u01E@public.gmane.org>
2008-04-15 16:12 ` Trond Myklebust
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=78295.47709.qm@web32602.mail.mud.yahoo.com \
--to=spamtrap-ys4e+72pfw0hfhg+jk9f0w@public.gmane.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@fys.uio.no \
/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