mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Samuel Maftoul <maftoul@esrf.fr>
To: linux-kernel@vger.kernel.org
Subject: NFS problem
Date: Thu, 22 Nov 2001 09:52:51 +0100	[thread overview]
Message-ID: <20011122095251.A18254@pcmaftoul.esrf.fr> (raw)

Hello,
        I have a QFS filesystem on a solaris 8 which is exported via
NFS:
qfs1                 2848604160 3996672 2844607488     1%
/data/id19/inhouse

([3] % uname -a 
SunOS azure 5.8 Generic_108528-09 sun4u sparc SUNW,Ultra-4 )

The QFS have an option on it's directories: you can change the attributes
on a directory with setfa (set file atrributes) to direct IO or page
cache.
Here is the concerned excerpt of the QFS setfa manpage:
"
     -D   Specifies the direct I/O attribute be permanently set
          for this file.  This means data is transferred directly
          between the user's buffer and disk.  This attribute
          should only be set for large block aligned sequential
          I/O.  The default I/O mode is buffered (uses the page
          cache).  Directio will not be used if the file is
          currently memory mapped.  See man directio(3C) for
          Solaris 2.6 and above for more details, however the
          SAM-FS directio attribute is permanent.
"
With this option we have strange performences:
>From a solaris client to this solaris server we have approximatively
40MB/s, with a linux client >1MB/s. Without directio mode we have
approximatively 20MB/s on a linux and 20MB/s on a solaris
( I have tested on several solaris clients, several linux client with
gigabit ethernet links and without (for having 20MB/s) ).

I thought that NFS's underlying FS do not have any effect on NFS
performances, and that the client is not aware of the ("local") remote
FS. 
Am I wrong ? 
Does anybody have an idea to fix the problem ? 
Is it a bug in NFS's implementation of linux kernel ?

Thanks in advance
        Sam

             reply	other threads:[~2001-11-22  8:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-22  8:52 Samuel Maftoul [this message]
2001-11-22 12:32 ` Trond Myklebust
2006-01-18  4:52 Conio sandiago
     [not found] <5wdAz-5a0-7@gated-at.bofh.it>
2006-01-18 13:55 ` Bodo Eggert
2006-01-18 14:58   ` Ram Gupta

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=20011122095251.A18254@pcmaftoul.esrf.fr \
    --to=maftoul@esrf.fr \
    --cc=linux-kernel@vger.kernel.org \
    /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

all inboxes | Powered by JetHome®