linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Robottom Reis <kiko@async.com.br>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: <NFS@lists.sourceforge.net>, <linux-kernel@vger.kernel.org>,
	<reiserfs-list@namesys.com>
Subject: Re: [NFS] NFS insanity
Date: Fri, 22 Jun 2001 12:57:24 -0300 (BRT)	[thread overview]
Message-ID: <Pine.LNX.4.32.0106221247390.183-100000@blackjesus.async.com.br> (raw)
In-Reply-To: <shsvgloisc2.fsf@charged.uio.no>

On 22 Jun 2001, Trond Myklebust wrote:

> I'm a bit surprised about your choice or rsize and wsize. Although it
> shouldn't make any difference, 3072 is not a natural size on an x86
> machine. You usually want something that divides PAGE_CACHE_SIZE=4096.
> Furthermore, on the Linux NFS client, any value < PAGE_CACHE_SIZE
> means that you use synchronous writes (deferred writes are enabled
> with wsize=4096 or greater).

Trond, your command was very much appreciated. I got to this value after
stress testing the network install in the office: anything above that
value caused massive collisions on the hub and I just thought it would be
unhealthy to be forcing this sort of bustage onto the wire. 1 and 2k
performed worse, and 4k causing collisions, I chose 3k. The tests
consisted of doing compiles and simple file operations (reading large mail
folders, in addition), which is what users doing everyday work here and
evaluating the performance of the filesystem look for.

I'm not _entirely_ sure my tests were sane, but is this a reasonable
explanation?

> The advantage in this case though, is that it means any error message
> that was returned by the server was guaranteed to have been received
> by 'cp', because the page was written to the server immediately.

And no error was reported; it was completely silent. I can no longer
reproduce this after the power outage we had yesterday forced a reboot on
the client. *sigh* It would have been nice to find out what it was.

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311



      reply	other threads:[~2001-06-22 15:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-20 23:23 NFS insanity Christian Robottom Reis
2001-06-21 13:59 ` [reiserfs-list] " Chris Mason
2001-06-21 14:58   ` Trond Myklebust
2001-06-21 15:10 ` [NFS] " Trond Myklebust
2001-06-21 22:43   ` Christian Robottom Reis
2001-06-22 12:58     ` Trond Myklebust
2001-06-22 15:57       ` Christian Robottom Reis [this message]

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=Pine.LNX.4.32.0106221247390.183-100000@blackjesus.async.com.br \
    --to=kiko@async.com.br \
    --cc=NFS@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=reiserfs-list@namesys.com \
    --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;
as well as URLs for NNTP newsgroup(s).