From: Pete Zaitcev <zaitcev@redhat.com>
To: Rainer Krienke <krienke@uni-koblenz.de>
Cc: Pete Zaitcev <zaitcev@redhat.com>,
linux-kernel@vger.kernel.org, nfs@lists.sourceforge.net
Subject: Re: 2.4.17:Increase number of anonymous filesystems beyond 256?
Date: Fri, 25 Jan 2002 12:41:10 -0500 [thread overview]
Message-ID: <20020125124110.A357@devserv.devel.redhat.com> (raw)
In-Reply-To: <mailman.1011275640.16596.linux-kernel2news@redhat.com> <200201240858.g0O8wnH03603@bliss.uni-koblenz.de> <20020124121649.A7722@devserv.devel.redhat.com> <200201250728.g0P7SDH26738@bliss.uni-koblenz.de>
In-Reply-To: <200201250728.g0P7SDH26738@bliss.uni-koblenz.de>; from krienke@uni-koblenz.de on Fri, Jan 25, 2002 at 08:28:13AM +0100
> From: Rainer Krienke <krienke@uni-koblenz.de>
> Date: Fri, 25 Jan 2002 08:28:13 +0100
> > Rainer, you missed the point. Nobody cares about small things
> > such as "cannot start nfsd" while your 4096 mounts patch
> > simply CORRUPTS YOUR DATA TO HELL.
>
> Well I never said, I really knew what I was doing:-). Thats exacly why I
> asked about why to use more major devices? OK the anser to this question
> seems to be that minor devices may only be 8 bit due to the static nature of
> some kernel structures. Right?
Close enough... Actual reason is the implementation of MINOR().
> > If you need more than 1200 mounts, you have to add more majors
> > to my patch. There is a number of them between 115 and 198.
> > I suspect scalability problems may become evident
> > with this approach, but it will work.
>
> The solution Richard posted seems to be interesting at this point isn't it?
I thought about the rgooch's suggestion, it sounds good for 2.5.
Red Hat do not ship devfs enabled currently, and I cannot use his
allocation function if someone uses static majors, or some modules
may not load. The patch does include a safety element (majorhog_xxx)
that reserves majors properly. The devfs would make that unnecessary.
-- Pete
next prev parent reply other threads:[~2002-01-25 17:41 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.1011275640.16596.linux-kernel2news@redhat.com>
2002-01-17 18:55 ` 2.4.17:Increase number of anonymous filesystems beyond 256? Pete Zaitcev
2002-01-18 12:12 ` Rainer Krienke
2002-01-18 19:40 ` H. Peter Anvin
2002-01-20 10:33 ` Rainer krienke
2002-01-20 10:37 ` H. Peter Anvin
2002-01-18 20:33 ` Horst von Brand
2002-01-19 22:07 ` H. Peter Anvin
2002-01-21 22:54 ` Pete Zaitcev
2002-01-18 12:26 ` Trond Myklebust
2002-01-21 12:40 ` Rainer Krienke
2002-01-22 10:25 ` Rainer Krienke
2002-01-22 10:40 ` Trond Myklebust
2002-01-22 13:08 ` Rainer Krienke
2002-01-22 13:28 ` Trond Myklebust
2002-01-22 15:23 ` Rainer Krienke
2002-01-22 15:40 ` Trond Myklebust
2002-01-22 17:45 ` Pete Zaitcev
2002-01-24 8:58 ` Rainer Krienke
2002-01-24 17:16 ` Pete Zaitcev
2002-01-24 17:29 ` Richard Gooch
2002-01-25 7:28 ` Rainer Krienke
2002-01-25 17:41 ` Pete Zaitcev [this message]
2002-01-25 18:34 ` Richard Gooch
2002-01-25 18:42 ` Pete Zaitcev
2002-01-22 19:45 ` Pete Zaitcev
[not found] <200201171351.g0HDpdK05456@bliss.uni-koblenz.de.suse.lists.linux.kernel>
2002-01-17 17:49 ` Andi Kleen
2002-01-17 13:51 Rainer Krienke
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=20020125124110.A357@devserv.devel.redhat.com \
--to=zaitcev@redhat.com \
--cc=krienke@uni-koblenz.de \
--cc=linux-kernel@vger.kernel.org \
--cc=nfs@lists.sourceforge.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.