All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Staubach <staubach@redhat.com>
To: Dan Stromberg <strombrg@dcs.nac.uci.edu>
Cc: Greg Banks <gnb@sgi.com>, nfs@lists.sourceforge.net
Subject: Re: Some code, and a question
Date: Wed, 07 Sep 2005 13:25:56 -0400	[thread overview]
Message-ID: <431F22A4.8000007@redhat.com> (raw)
In-Reply-To: <431F1FD5.4@redhat.com>

Peter Staubach wrote:

>>
>> No I haven't - great lead.  I'll see if I can google that up.  Or if you
>> have the incantation at your fingertips...
>>
>
> For Solaris, you might check out adding something like:
>
>    set nfs:nfs3_max_transfer_size=1048576
>    set nfs:nfs4_max_transfer_size=1048576
>
> to /etc/system and then reboot the system.  This will increase the 
> maximum
> size of a transfer to 1M.  Alternately, you could use adb to patch a 
> running
> system.  The command, "nfsstat -m", should tell you what the limits 
> are for
> currently mounted file systems.  You will need to umount and mount any
> existing NFS mounted file systems in order for them to be able to use the
> new limits. 


You will probably need to increase the NFS client side blocksize
as well.  This is nfs[34]_bsize.  So, something like:

    set nfs:nfs3_bsize=1048576
    set nfs:nfs4_bsize=1048576

although, you will probably want it to match your rsize/wsize settings.

Please be aware that the if the block size is bigger than the transfer
size, then the Solaris NFS client will do break up the block sized
transfers into multiple pieces and then do them sequentially.

So, there is a tie between the read transfer size and the write transfer
size, at least on a Solaris client.

    Thanx...

       ps


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  reply	other threads:[~2005-09-07 17:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-06 22:39 Some code, and a question Dan Stromberg
2005-09-07  1:02 ` Greg Banks
2005-09-07 14:37   ` Dan Stromberg
2005-09-07 14:55     ` Peter Staubach
2005-09-07 17:00       ` Dan Stromberg
2005-09-07 17:13         ` Peter Staubach
2005-09-07 17:25           ` Peter Staubach [this message]
2005-09-07 17:28           ` Dan Stromberg
2005-09-07 17:27             ` Peter Staubach
  -- strict thread matches above, loose matches on Subject: below --
2005-09-07 15:34 Lever, Charles
2005-09-07 17:02 ` Dan Stromberg

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=431F22A4.8000007@redhat.com \
    --to=staubach@redhat.com \
    --cc=gnb@sgi.com \
    --cc=nfs@lists.sourceforge.net \
    --cc=strombrg@dcs.nac.uci.edu \
    /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.