All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Waychison <Michael.Waychison@Sun.COM>
To: Ian Kent <raven@themaw.net>
Cc: "Ogden, Aaron A." <aogden@unocal.com>,
	autofs mailing list <autofs@linux.kernel.org>,
	nfs@lists.sourceforge.net,
	Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Joseph V Moss <jmoss@ichips.intel.com>
Subject: Re: [NFS] RE: multiple servers per automount
Date: Tue, 14 Oct 2003 11:52:22 -0400	[thread overview]
Message-ID: <3F8C1BB6.9010202@sun.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0310142131090.3044-100000@raven.themaw.net>

Ian Kent wrote:

>On Tue, 14 Oct 2003, Joseph V Moss wrote:
>
>  
>
>>The limit is 800 as others have stated.  Although, it can be less than that
>>if something else is already using up some of the reserved UDP ports.
>>
>>I wrote a patch long ago against a 2.2.x kernel to enable it to use
>>multiple majors for NFS mounts (like the patches now common in several
>>distros).  I then ran into the 800 limit in the RPC layer.  After changing
>>the RPC layer to count up from 0, instead of down from 800, with no real
>>upper limit, I was able to mount more than 2000 NFS filesystems simultaneously.
>>I'm sure I could have done many thousand if I had had that many filesystems
>>around to mount.  Obviously, after 1024, it wasn't using reserved ports
>>anymore, but it didn't seem to matter.
>>
>>Unfortunately, while the changes to NFS were easy to port to the 2.4 kernel,
>>the RPC layer is different enough between 2.2 and 2.4 that it didn't work
>>right off.  Bumping it up to somewhere around 1024 should work, but using
>>non-reserved ports didn't seem to work when I made a simple attempt.
>>
>>Of course, the real fix for the NFS layer is the expansion of the minor
>>numbers that's already occurred in 2.6 and the RPC layer problems should
>>be fixed by multiplexing multiple mounts on the same port.
>>
>>
>>    
>>
>
>I don't see that expansion in 2.6 (test6). It looks to me like the 
>allocation is done in set_anon_super (in fs/super.c) and that looks like 
>it is restricted to 256. Please correct this for me. I can't see how there 
>is any change to the number of unnmaed devices.
>
>  
>

Here is the quick fix for this in RH 2.1AS kernels:

http://www.kernelnewbies.org/kernels/rh21as/SOURCES/linux-2.4.9-moreunnamed.patch

It makes unnamed block devices use majors 12, 14, 38, 39, as well as 0. 

I don't know if anyone is working out a better scheme for 
get_unnamed_dev in 2.6 yet.  It does need to be done though.  A simple 
patch for 2.6 would maybe see the unnamed_dev_in_use bitmap grow to 
PAGE_SIZE, automatically allowing for 32768 unnamed devices.

Mike Waychison

WARNING: multiple messages have this Message-ID (diff)
From: Mike Waychison <Michael.Waychison@Sun.COM>
To: Ian Kent <raven@themaw.net>
Cc: Joseph V Moss <jmoss@ichips.intel.com>,
	"Ogden, Aaron A." <aogden@unocal.com>,
	autofs mailing list <autofs@linux.kernel.org>,
	nfs@lists.sourceforge.net,
	Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [NFS] RE: [autofs] multiple servers per automount
Date: Tue, 14 Oct 2003 11:52:22 -0400	[thread overview]
Message-ID: <3F8C1BB6.9010202@sun.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0310142131090.3044-100000@raven.themaw.net>

Ian Kent wrote:

>On Tue, 14 Oct 2003, Joseph V Moss wrote:
>
>  
>
>>The limit is 800 as others have stated.  Although, it can be less than that
>>if something else is already using up some of the reserved UDP ports.
>>
>>I wrote a patch long ago against a 2.2.x kernel to enable it to use
>>multiple majors for NFS mounts (like the patches now common in several
>>distros).  I then ran into the 800 limit in the RPC layer.  After changing
>>the RPC layer to count up from 0, instead of down from 800, with no real
>>upper limit, I was able to mount more than 2000 NFS filesystems simultaneously.
>>I'm sure I could have done many thousand if I had had that many filesystems
>>around to mount.  Obviously, after 1024, it wasn't using reserved ports
>>anymore, but it didn't seem to matter.
>>
>>Unfortunately, while the changes to NFS were easy to port to the 2.4 kernel,
>>the RPC layer is different enough between 2.2 and 2.4 that it didn't work
>>right off.  Bumping it up to somewhere around 1024 should work, but using
>>non-reserved ports didn't seem to work when I made a simple attempt.
>>
>>Of course, the real fix for the NFS layer is the expansion of the minor
>>numbers that's already occurred in 2.6 and the RPC layer problems should
>>be fixed by multiplexing multiple mounts on the same port.
>>
>>
>>    
>>
>
>I don't see that expansion in 2.6 (test6). It looks to me like the 
>allocation is done in set_anon_super (in fs/super.c) and that looks like 
>it is restricted to 256. Please correct this for me. I can't see how there 
>is any change to the number of unnmaed devices.
>
>  
>

Here is the quick fix for this in RH 2.1AS kernels:

http://www.kernelnewbies.org/kernels/rh21as/SOURCES/linux-2.4.9-moreunnamed.patch

It makes unnamed block devices use majors 12, 14, 38, 39, as well as 0. 

I don't know if anyone is working out a better scheme for 
get_unnamed_dev in 2.6 yet.  It does need to be done though.  A simple 
patch for 2.6 would maybe see the unnamed_dev_in_use bitmap grow to 
PAGE_SIZE, automatically allowing for 32768 unnamed devices.

Mike Waychison


  reply	other threads:[~2003-10-14 15:52 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-10 15:16 multiple servers per automount Ogden, Aaron A.
2003-10-13  3:23 ` [NFS] " Ian Kent
2003-10-14  7:05   ` Joseph V Moss
2003-10-14 13:37     ` RE: [autofs] " Ian Kent
2003-10-14 13:37       ` Ian Kent
2003-10-14 15:52       ` Mike Waychison [this message]
2003-10-14 15:52         ` [NFS] " Mike Waychison
2003-10-14 20:44         ` H. Peter Anvin
2003-10-14 23:12           ` Mike Waychison
2003-10-15 10:28             ` Ingo Oeser
2003-10-15 16:16               ` Mike Waychison
2003-10-23 13:37               ` Ian Kent
2003-10-23 17:00                 ` Mike Waychison
2003-10-23 17:09                   ` Tim Hockin
2003-10-24  0:47                   ` Ian Kent
2003-10-24  1:42                     ` Tim Hockin
2003-10-15  7:22         ` Ian Kent
2003-10-15  7:22           ` [NFS] " Ian Kent
2003-10-15  7:22           ` Ian Kent
  -- strict thread matches above, loose matches on Subject: below --
2003-10-10 17:02 [NFS] " Eric Werme USG
2003-10-10 15:43 Ogden, Aaron A.
2003-10-10 15:54 ` Mike Waychison
2003-10-10 15:10 Re: [autofs] " Lever, Charles
2003-10-13  3:05 ` [NFS] " Ian Kent

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=3F8C1BB6.9010202@sun.com \
    --to=michael.waychison@sun.com \
    --cc=aogden@unocal.com \
    --cc=autofs@linux.kernel.org \
    --cc=jmoss@ichips.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nfs@lists.sourceforge.net \
    --cc=raven@themaw.net \
    /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.