Re: [patch for playing] Patch to support 4000 disks and maintain backward compatibility

Badari Pulavarty (pbadari@us.ibm.com)
Thu, 10 Apr 2003 15:22:41 -0700


On Thursday 10 April 2003 03:09 pm, Andries.Brouwer@cwi.nl wrote:

>
> I try to make sure there are no assumptions about the
> size or structure of device numbers anywhere outside kdev_t.h.
> In particular I object to the use of KDEV_MINOR_BITS.
>
> Apart from this formal point, there is also the practical point:
> suppose 64 = 32+32 is used, so that KDEV_MINOR_BITS equals 32.
> Then LAST_MAJOR_DISKS is 2^28 and sd_index_bits[] would be 32 MB array.
> Unreasonable.

agreed !! (I mentioned this ealier in my previous postings - sd_index_bits[]
array size)

>
> The conclusion is that the easy way out is to define MAX_NR_DISKS.

Unfortunately, MAX_NR_DISK will be dependent on KDEV_MINOR_BITS.
We can't set MAX_NR_DISKS to arbitrary value and if there are not
enought MINOR bits, it won't work. Only way to make this work is
to do dynamic major allocation and update /dev/ entries for them.

> A different way out, especially when we use 32+32, is to kill this
> sd_index_bits[] array, and give each disk a new number: replace
> index = find_first_zero_bit(sd_index_bits, SD_DISKS);
> by
> index = next_index++;
>
I wish it is that simple. We use sd_index_bits[] since we could
sd_detach() and then sd_attach() few disks. We will end up with
holes, name slippage without this. We need to know what disks are
currently being in use.

Thanks,
Badari

-
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/