Luca Berra <bluca@xxxxxxxxxx> writes: > On Wed, Mar 26, 2008 at 12:43:41PM +0100, Ferenc Wagner wrote: > >> I use an FC SAN, which provides multiple pathes to multiple LUNs. >> These all come up as different sd* devices, exhausting single letter >> names. I mean they are a LOT. Using the md mulitpath driver >> everything works perfectly, no problems there. However, during boot, >> the kernel tries to read the partition table from each device, >> spitting out hundreds of lines of error messages: most of the devices >> aren't even readable, and those which are, don't contain a valid >> partition table. They never will. So I'd like to disable partition >> detection, because these messages overflow the kernel message buffer, >> depriving syslog of gathering any useful boot messages, and also >> needlessly lengthening the boot process. (Of course the noise alone >> is disturbing enough when one tries to troubleshoot a boot problem.) >> However, looking at the kernel sources didn't give me any hint. Is >> this possible to disable at all? > > you could try bugging lkml until it dawns on them that partition > detection code should belong in userspace by default :) :) Very well put. Thanks for strenghtening my belief. > anyway you can rebuild your own kernel disabling it > just set PARTITION_ADVANCED, and disable all partition types. Sounds like a good idea, will try that! This makes bugging lkml unnecessary, if not for changing the default... But that's more a distribution issue, I think. And now that we have udev and kpartx, things will probably drift in this direction. > you should be aware that doing this will disable partition detection on > all drives, so if you have partitioned drives (eg boot drives) you have > to run partx in initramfs or it wont be able to access them. Not in this case. I'm netbooting and getting / and co. from the SAN via multipath and LVM, not a single partition on the whole cluster... -- Thanks for the tip! Feri. -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
