----- "Bob Montgomery" <bob.montgomery@xxxxxx> wrote:
> On Mon, 2009-06-08 at 19:50 +0000, Dave Anderson wrote:
>
> Regarding blkext 259
> >
> > Correction -- it does appear in the major_names[] array, in a
> 2.6.30
> > kernel for example, like this:
> >
> > crash> p * major_names[4]
> > $51 = {
> > next = 0x0,
> > major = 259,
> > name = "blkext\000\000\000\000\000\000\000\000\000"
> > }
> >
> > where it appears to be the only major_names[] entry whose "major"
> value
> > doesn't equal the index into the array (i.e., 259 != 4). But the
> > bdev_map.probes[4] entry is unused.
>
> The blkext is supposed to get used as soon as someone wants to put more
> than 15 partitions on an sd disk. (Explanation at
> http://thread.gmane.org/gmane.linux.kernel/701825)
>
> Then the upper partitions will appear as minors of 259. When that
> starts happening more, having a way to see it might (*might*) be
> interesting.
>
> > > At this point I'm about ready to deprecate the whole command...
> ;-)
>
> And at this point I couldn't really argue much :-) I obviously hadn't
> used the command for a while. I was casting around, hoping it would
> maybe help me find the diskstats stuff for the block devices. I was
> trying to answer a question like "How much disk activity was going on
> before this crashed?"
>
> When I tried the dev command and it bombed at the chrdev stuff before
> getting to the blkdev stuff, I was motivated to get it going enough to
> see if it would help answer my question, but it doesn't print anything
> (like hd_struct pointers) that could help me with my problem. But I
> figured someone had once wanted that device info, so it might as well
> work...
OK, I understand...
But anyway, given the command's current capability, do you think that the
alternative -f option should just be thrown out, and that all devices
should be dumped regardless whether they have file_operations associated
with them or not?
Dave
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
