James Bottomley wrote: > On Tue, 2008-06-24 at 11:30 +0300, Boaz Harrosh wrote: >> James Bottomley wrote: >>> On Mon, 2008-06-23 at 17:04 -0400, Greg Freemyer wrote: >>>> I've seen a lot of end user complaints about libata only supporting >>>> 15(14?) partitions. Will that limit be moved back to the traditional >>>> drivers/ide limit as part of this? >>> Number of partitions is directly related to number of minors, so it >>> can't be changed without a change in the allocation of major/minor space >>> in sd ... that could only be done compatibly by permuting the space. >>> The only other way to do it is incompatibly by changing major (again). >>> >> Could we do both? I mean use the legacy, up to 15, with the old major, >> then use the new major for bigger then 15. Since user mode that knows >> about more then 15 partitions is new, it'll know it needs to jump a major. > > Not simultaneously, which is the problem; you can't have two separate > block devices for the same physical device unless you want aliasing > issues in the page cache. > > It might be possible to add an extra device to give access to the > missing partitions, but that would require a bit of re-engineering in > gendisk (which is the in-kernel code to manage the partitions). > > What might be far more feasible is to set up udev to use kpartx to > provide the missing partitions if it detects a partition table that has > them ... of course, that requires a udev setup and most of the > complaints about the lost partitions seem to come from non-udev systems. > > But .... if everyone (particularly the people with these problems) had > udev, we could simply migrate to a new major with more partitions, get > udev to fix it all up for us and everyone would be happy because no-one > would even notice that we'd moved majors ... I'm currently working on a scheme where partitions above gd->minors get allocated dynamic MAJ:MIN. It looks like it can be done mostly in block layer proper. The only problem I can foresee is not being able to specify MAJ:MIN as root device but that shouldn't be a major problem. I'll report back when I make more progress. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
