Pete Zaitcev writes:
> > From: Rainer Krienke <krienke@uni-koblenz.de>
> > Date: Thu, 24 Jan 2002 09:58:48 +0100
>
> > diff -Naur linux-2.4.17.orig/fs/super.c linux-2.4.17/fs/super.c
> > --- linux-2.4.17.orig/fs/super.c Fri Dec 21 18:42:03 2001
> > +++ linux-2.4.17/fs/super.c Thu Jan 24 08:23:05 2002
> > @@ -489,13 +489,13 @@
> > * filesystems which don't use real block-devices. -- jrs
> > */
> >
> > -static unsigned long unnamed_dev_in_use[256/(8*sizeof(unsigned long))];
> > +static unsigned long unnamed_dev_in_use[4096/(8*sizeof(unsigned long))];
> >
> > kdev_t get_unnamed_dev(void)
> > {
> > int i;
> >
> > - for (i = 1; i < 256; i++) {
> > + for (i = 1; i < 4096; i++) {
> > if (!test_and_set_bit(i,unnamed_dev_in_use))
> > return MKDEV(UNNAMED_MAJOR, i);
> > }
> >[...]
> > mount a very high number only limited by the bitmap unnamed_dev_in_use of NFS
> > directories. The problems are:
>
> 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.
>
> 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.
>
> Trond asked if I requested numbers from HPA, and the answer is no,
> because I wanted the patch in circulation for a while before it
> is worth bothering. Also, I heard that LANA is closed anyways.
You can use devfs_alloc_major() to safely grab unassigned majors.
If necessary, I can move this to a generic area.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jan 31 2002 - 21:00:22 EST