From: Fengguang Wu <wfg-fOMaevN1BEbsJZF79Ady7g@public.gmane.org>
To: saeed bishara <saeed.bishara@gmail.com>
Cc: Jeff Garzik <jeff@garzik.org>,
linux-kernel@vger.kernel.org,
NFS list <linux-nfs@vger.kernel.org>
Subject: Re: read-ahead in NFS server
Date: Fri, 28 Dec 2007 10:33:21 +0800 [thread overview]
Message-ID: <398809213.08803@ustc.edu.cn> (raw)
Message-ID: <E1J852H-0002K7-P1@localhost> (raw)
In-Reply-To: <c70ff3ad0712270700h6336b194r7c21834423aeb331-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Dec 27, 2007 at 05:00:12PM +0200, saeed bishara wrote:
> > >> Are you using TCP? Are you using NFSv4, or an older version?
> > > I'm using NFSv3/UDP.
> >
> > IMO, you definitely want TCP and NFSv4. Much better network behavior,
> > with some of the silly UDP limits (plus greatly improved caching
> > behavior, due to v4 delegations).
> the clients of my system going to be embedded system with low
> performance cpus and I need UDP as it needs less cpu power.
You can try the attached adaptive readahead patch.
Apply it on your server and compile kernel with CONFIG_ADAPTIVE_READAHEAD.
Use large 1MB readahead on server and small readahead on clients.
> > > when I run local dd with bs=4K, I can see that the average IO size is
> > > more than 300KB.
> >
> > Read-ahead is easier in NFSv4, because the client probably has the file
> > delegated locally, and has far less need to constantly revalidate file
> > mapping(s).
> I'll check that.
> but what about the server side? why the issued IO's are only as twice
> as the size of the NFS requests?
The readahead code is helpless in NFSv3 :-(
Use NFS over TCP and rsize=readahead=1MB on client side could help.
But if you prefer UDP, the above patch may help you :-)
Fengguang
WARNING: multiple messages have this Message-ID (diff)
From: Fengguang Wu <wfg@mail.ustc.edu.cn>
To: saeed bishara <saeed.bishara@gmail.com>
Cc: Jeff Garzik <jeff@garzik.org>,
linux-kernel@vger.kernel.org,
NFS list <linux-nfs@vger.kernel.org>
Subject: Re: read-ahead in NFS server
Date: Fri, 28 Dec 2007 10:33:21 +0800 [thread overview]
Message-ID: <E1J852H-0002K7-P1__18698.7322209918$1198809252$gmane$org@localhost> (raw)
Message-ID: <E1J852H-0002K7-P1@localhost> (raw)
In-Reply-To: <c70ff3ad0712270700h6336b194r7c21834423aeb331@mail.gmail.com>
On Thu, Dec 27, 2007 at 05:00:12PM +0200, saeed bishara wrote:
> > >> Are you using TCP? Are you using NFSv4, or an older version?
> > > I'm using NFSv3/UDP.
> >
> > IMO, you definitely want TCP and NFSv4. Much better network behavior,
> > with some of the silly UDP limits (plus greatly improved caching
> > behavior, due to v4 delegations).
> the clients of my system going to be embedded system with low
> performance cpus and I need UDP as it needs less cpu power.
You can try the attached adaptive readahead patch.
Apply it on your server and compile kernel with CONFIG_ADAPTIVE_READAHEAD.
Use large 1MB readahead on server and small readahead on clients.
> > > when I run local dd with bs=4K, I can see that the average IO size is
> > > more than 300KB.
> >
> > Read-ahead is easier in NFSv4, because the client probably has the file
> > delegated locally, and has far less need to constantly revalidate file
> > mapping(s).
> I'll check that.
> but what about the server side? why the issued IO's are only as twice
> as the size of the NFS requests?
The readahead code is helpless in NFSv3 :-(
Use NFS over TCP and rsize=readahead=1MB on client side could help.
But if you prefer UDP, the above patch may help you :-)
Fengguang
next prev parent reply other threads:[~2007-12-28 2:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-26 11:51 read-ahead in NFS server saeed bishara
[not found] ` <c70ff3ad0712260351i6583aa8dpbf16ed606a634b1f-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2007-12-27 2:34 ` Jeff Garzik
2007-12-27 2:34 ` Jeff Garzik
2007-12-27 8:50 ` saeed bishara
[not found] ` <c70ff3ad0712270050u134616d1q459ed073c586dcec-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2007-12-27 11:54 ` Jeff Garzik
2007-12-27 11:54 ` Jeff Garzik
2007-12-27 15:00 ` saeed bishara
[not found] ` <c70ff3ad0712270700h6336b194r7c21834423aeb331-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2007-12-27 15:07 ` Jeff Garzik
2007-12-27 15:07 ` Jeff Garzik
2007-12-27 15:38 ` saeed bishara
2007-12-28 2:33 ` Fengguang Wu [this message]
2007-12-28 2:33 ` Fengguang Wu
2007-12-28 2:33 ` Fengguang Wu
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=398809213.08803@ustc.edu.cn \
--to=wfg-fomaevn1bebsjzf79ady7g@public.gmane.org \
--cc=jeff@garzik.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=saeed.bishara@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.