Re: 2.4.17:Increase number of anonymous filesystems beyond 256?

[Richard Gooch]

[Note: nfs-list removed from Cc:ed because slow^Wsourcefore has a
broken mail configuration which always bounces my email]

Pete Zaitcev writes:
> > From: Rainer Krienke <[e-mail]>
> > 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.

The allocation function should be safe, since it only gives majors
which are not assigned in devices.txt. Drivers which statically grab
unassigned majors are broken, and *will* trip over each other at some
point.

As I said before, I can move the major allocation function into a
generic place and not have it depend on CONFIG_DEVFS_FS. So it doesn't
have to matter if RH ship devfs or not.

BTW: please Cc: me, otherwise I may not see responses.

				Regards,

					Richard....
Permanent: [e-mail]
Current:   [e-mail]