headers
Chuck Lever | 1 Jul 2008 01:00
Picon
Favicon

[PATCH 15/16] lockd: Adjust nlmsvc_lookup_host() to accomodate non-AF_INET

Fix up nlmsvc_lookup_host() to pass non-AF_INET source addresses to
nlm_lookup_host().

Signed-off-by: Chuck Lever <chuck.lever@...>
---

 fs/lockd/host.c             |   51 +++++++++++++++++++++++++++++++++++--------
 include/linux/lockd/lockd.h |    5 +++-
 2 files changed, 44 insertions(+), 12 deletions(-)

diff --git a/fs/lockd/host.c b/fs/lockd/host.c
index 3c7916d..73e234a 100644
--- a/fs/lockd/host.c
+++ b/fs/lockd/host.c
 <at>  <at>  -305,29 +305,60  <at>  <at>  struct nlm_host *nlmclnt_lookup_host(const struct sockaddr *sap,
 	return nlm_lookup_host(&ni);
 }

-/*
- * Find an NLM client handle in the cache. If there is none, create it.
+/**
+ * nlmsvc_lookup_host - Find an NLM host handle matching a remote client
+ *  <at> rqstp: incoming NLM request
+ *  <at> hostname: name of client host
+ *  <at> hostname_len: length of client hostname
+ *
+ * Returns an nlm_host structure that matches the [client address,
+ * transport protocol, NLM version, client hostname] of the passed-in
+ * NLM request.  If one doesn't already exist in the host cache, a
+ * new handle is created and returned.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chuck Lever | 1 Jul 2008 01:00
Picon
Favicon

[PATCH 16/16] lockd: change nlmclnt_grant() to take a "struct sockaddr *"

Adjust the signature and callers of nlmclnt_grant() to pass a "struct
sockaddr *" instead of a "struct sockaddr_in *" in order to support IPv6
addresses.

Signed-off-by: Chuck Lever <chuck.lever@...>
---

 fs/lockd/clntlock.c         |    5 ++---
 fs/lockd/svc4proc.c         |    2 +-
 fs/lockd/svcproc.c          |    2 +-
 include/linux/lockd/lockd.h |    3 ++-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/fs/lockd/clntlock.c b/fs/lockd/clntlock.c
index 9eaf306..2976bf0 100644
--- a/fs/lockd/clntlock.c
+++ b/fs/lockd/clntlock.c
 <at>  <at>  -141,7 +141,7  <at>  <at>  int nlmclnt_block(struct nlm_wait *block, struct nlm_rqst *req, long timeout)
 /*
  * The server lockd has called us back to tell us the lock was granted
  */
-__be32 nlmclnt_grant(const struct sockaddr_in *addr, const struct nlm_lock *lock)
+__be32 nlmclnt_grant(const struct sockaddr *addr, const struct nlm_lock *lock)
 {
 	const struct file_lock *fl = &lock->fl;
 	const struct nfs_fh *fh = &lock->fh;
 <at>  <at>  -165,8 +165,7  <at>  <at>  __be32 nlmclnt_grant(const struct sockaddr_in *addr, const struct nlm_lock *lock
 		 */
 		if (fl_blocked->fl_u.nfs_fl.owner->pid != lock->svid)
 			continue;
(Continue reading)

Permalink | Reply | 0 comments |
headers
J. Bruce Fields | 1 Jul 2008 01:34

server rdma todo's

I've got a few very small server-rdma todo's lying around; would you be
the right person to help with them?

	- Documentation on nfsrdma security issues.  (Examples of setup
	  that would be secure, under what asssumptions, etc.)
	- Fix Kconfig rmda help to mention server too.

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 2 comments |
headers
Krishna Kumar2 | 1 Jul 2008 05:43
Picon

Re: NFS performance degradation of local loopback FS.

Hi Chuck,

> As I understand it, "lo" is effectively a virtualized network device
> with point-to-point routing.  Looping back through a real NIC can, in
> many cases, go all the way down to the network hardware and back, and
> is likely subject to routing decisions in your system's network layer.
>  So I would expect them to be different in most cases.

Atleast in the linux stack, if you address a local network device, the
kernel does a route lookup to figure out which interface to send the
packet out on, and this results in using lo.

Thanks,

- KK

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Krishna Kumar2 | 1 Jul 2008 07:07
Picon

Re: NFS performance degradation of local loopback FS.

Jeff Layton <jlayton@...> wrote on 06/30/2008 08:56:54 PM:

> Recently I spent some time with others here at Red Hat looking
> at problems with nfs server performance. One thing we found was that
> there are some problems with multiple nfsd's. It seems like the I/O
> scheduling or something is fooled by the fact that sequential write
> calls are often handled by different nfsd's. This can negatively
> impact performance (I don't think we've tracked this down completely
> yet, however).
>
> Since you're just doing some single-threaded testing on the client
> side, it might be interesting to try running a single nfsd and testing
> performance with that. It might provide an interesting data point.

Works perfectly now!

With 64 nfsd's:
[root <at> localhost nfs]# ./perf
      ********** Testing on /nfs *************
      Read Time: 50.6236      BW:29.63 MB/s
      ********** Testing on /local *************
      Read Time: 38.3506      BW:39.11 MB/s

With 1 nfs'd:
[root <at> localhost nfs]# ./perf
      ********** Testing on /nfs *************
      Read Time: 38.4760      BW:38.99 MB/s
      ********** Testing on /local *************
      Read Time: 38.4874      BW:38.97 MB/s
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carsten Aulbert | 1 Jul 2008 08:24
Picon

[NFS] Massive NFS problems on large cluster with large number of mounts

Hi all,

I do hope my email gets through, I tried to subscribe yesterday but with
no effect so far.

We are running a large cluster and do a lot of cross-mounting between
the nodes. To get this running we are running a lot of nfsd (196) and
use mountd with 64 threads, just in case we get a massive number of hits
onto a single node. All this is on Debian Etch with a recent 2.6.24
kernel using autofs4 at the moment to do the automounts.

When running these two not nice scripts:

$ cat test_mount
#!/bin/sh

n_node=1000

for i in `seq 1 $n_node`;do
        n=`echo $RANDOM%1342+10001 | bc| sed -e "s/1/n/"`
        $HOME/bin/mount.sh $n&
        echo -n .
done

$ cat mount.sh
#!/bin/sh

dir="/distributed/spray/data/EatH/S5R1"

ping -c1 -w1 $1 > /dev/null&& file="/atlas/node/$1$dir/"`ls -f
(Continue reading)

Permalink | Reply | 2 comments |
headers
NeilBrown | 1 Jul 2008 09:10
Picon
Gravatar

nfs@... subscription

On Tue, July 1, 2008 4:24 pm, Carsten Aulbert wrote:
> Hi all,
>
> I do hope my email gets through, I tried to subscribe yesterday but with
> no effect so far.
>

It takes me a day or two to get to these sometimes.  But I always
reject them asking you to subscribe to linux-nfs@...
as it is a better managed list (and this is gatewayed to that).

But your mail did get through.

Where did you get the address of this list from Carsten?  We should
fix it if we can.

Just a reminder to everyone still subscribed to nfs@...
(there are still 466 of you) - please unsubscribe from
  nfs@...
and (if you want) subscribe to
  linux-nfs@...
Until you do, you are missing a lot of stuff, as many people only
post to that later list now.

As it says at the bottom over every mail to this list:

> Please note that nfs@... is being discontinued.
> Please subscribe to linux-nfs@... instead.
>     http://vger.kernel.org/vger-lists.html#linux-nfs
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Carsten Aulbert | 1 Jul 2008 09:24
Picon

nfs@... subscription

Hi Neil,

NeilBrown wrote:
> It takes me a day or two to get to these sometimes.  But I always
> reject them asking you to subscribe to linux-nfs@...
> as it is a better managed list (and this is gatewayed to that).

Yes, seen that and already asked vger to subscribe.. but that usually
takes a while :)

> 
> But your mail did get through.
> 

Good, I'll repost it once I'm subscribe to the new list

> Where did you get the address of this list from Carsten?  We should
> fix it if we can.
> 

Easy:

Search for NFS on Google and one of the top hits is the SF page which
directly links to the old list:
http://nfs.sourceforge.net/

Thanks for the reminder!

Cheers
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carsten Aulbert | 1 Jul 2008 10:19
Picon

Massive NFS problems on large cluster with large number of mounts

Hi all (now to the right email list),

We are running a large cluster and do a lot of cross-mounting between
the nodes. To get this running we are running a lot of nfsd (196) and
use mountd with 64 threads, just in case we get a massive number of hits
onto a single node. All this is on Debian Etch with a recent 2.6.24
kernel using autofs4 at the moment to do the automounts.

When running these two not nice scripts:

$ cat test_mount
#!/bin/sh

n_node=1000

for i in `seq 1 $n_node`;do
        n=`echo $RANDOM%1342+10001 | bc| sed -e "s/1/n/"`
        $HOME/bin/mount.sh $n&
        echo -n .
done

$ cat mount.sh
#!/bin/sh

dir="/distributed/spray/data/EatH/S5R1"

ping -c1 -w1 $1 > /dev/null&& file="/atlas/node/$1$dir/"`ls -f
/atlas/node/$1$dir/|head -n 50 | tail -n 1`
md5sum ${file}
(Continue reading)

Permalink | Reply | 28 comments |
headers
Krishna Kumar2 | 1 Jul 2008 12:19
Picon

Re: NFS performance degradation of local loopback FS.

"J. Bruce Fields" <bfields@...> wrote on 06/30/2008 09:05:41 PM:

> On Mon, Jun 30, 2008 at 11:26:54AM -0400, Jeff Layton wrote:
> > Recently I spent some time with others here at Red Hat looking
> > at problems with nfs server performance. One thing we found was that
> > there are some problems with multiple nfsd's. It seems like the I/O
> > scheduling or something is fooled by the fact that sequential write
> > calls are often handled by different nfsd's. This can negatively
> > impact performance (I don't think we've tracked this down completely
> > yet, however).
>
> Yes, we've been trying to see how close to full network speed we can get
> over a 10 gig network and have run into situations where increasing the
> number of threads (without changing anything else) seems to decrease
> performance of a simple sequential write.
>
> And the hypothesis that the problem was randomized IO scheduling was the
> first thing that came to mind.  But I'm not sure what the easiest way
> would be to really prove that that was the problem.
>
> And then once we really are sure that's the problem, I'm not sure what
> to do about it.  I suppose it may depend partly on exactly where the
> reordering is happening.

For 1 process, this theory seems to work:
1 testing process: /local:            39.11 MB/s
        64 nfsd's:                    29.63 MB/s
        1 nfs'd:                      38.99 MB/s

However for 6 processes reading 6 different files:
(Continue reading)

Permalink | Reply | 1 comment |

Gmane