Re: cvs commit: src/sys/kern subr_diskmbr.c
As Peter Wemm wrote: > Yes, that is much safer, however there are certain bioses that have > interesting quirks that the MBR has to work around. The problem > when overlapping mbr and boot1 into the same block is that we no > longer have the space to do that. boot1.s has got *3* bytes free. Too bad. Peter, do you care to update the section about DD mode (and its dangers) in the FAQ after all this discussion? I could probably do it, too (the original entry is mine), but i had to quote your arguments only anyway. > Also (and I think this is more likely to be the problem you ran > into) many newer PC's are looking at the partition tables for a > suspend-to-disk partition or a FAT filesystem with a suspend-to-disk > dump file. Seems i really love my Toshiba (Libretto) that simply hibernates to the last nnn MB of the physical disk. ;-) (I have reserved a FreeBSD partition as a placeholder for the hibernation data.) > However, there is light at the end of the tunnel. EFI GPT is pretty > clean. Good to hear. While this sounds like dedicated disks will be gone then :), at least the format looks rationale enough. > It supports up to something like 16384 partitions ... It would be interesting to see how Windoze will arrange for 16K "drive" letters. :-)) The day vinum is up and ready to also cover the root FS, i won't need /any/ partition at all anymore. ;-) As Greg Lehey wrote: > > ...73 of those silly messages are just beyond any form of usefulness. > Hadn't we agreed to do this? I'm certainly in favour of the > bootverbose approach. I can't remember any agreement so far. But thinking a bit more about it, it sounds like the best solution to me, too. The only other useful option would be to restrict the message to once per drive, but that'll cost an additional per-drive flag, which is probably too much effort just for that message. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
On Mon, Dec 10, 2001 at 10:49:28AM -0800, Matthew Dillon wrote:
>
> :For RAID3 that is true. For the other ones...
> :
> :> performance without it - for reading OR writing. It doesn't matter
> :> so much for RAID{1,10}, but it matters a whole lot for something like
> :> RAID-5 where the difference between a spindle-synced read or write
> :> and a non-spindle-synched read or write can be upwards of 35%.
> :
> :If you have RAID5 with I/O sizes that result in full-stripe operations.
> :
> :--
> :| / o / /_ _ email: [EMAIL PROTECTED]
> :|/|/ / / /( (_) Bulte Arnhem, The Netherlands
>
> Well, for reads a non-stripe-crossing op would still work reasonably
> well. But for writes less then full-stripe operations without
> spindle sync are going to be terrible due to the read-before-write
> requirement (to calculate parity). The disk cache is useless in that
> case.
Modern disks do prereads and writes are streamed by tagged command
queueing which invalidates this for linear access.
For non linear access the syncronisation is shadowed partly by different
seek times and different load on the spindles.
The chance that the data and parity spindle have the heads on the same
track is absolutely small for random access.
With 15000 upm drives the maximum rotational delay is 4ms and the
average is 2ms which gives you an maximum of only 1ms to gain under
ideal conditions - which we don't have as I stated above.
--
B.Walter COSMO-Project http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
On Monday, 10 December 2001 at 9:11:03 +0100, Joerg Wunsch wrote: > Also, i think that: > > uriah /boot/kernel/kernel: da0: invalid primary partition table: Dangerously >Dedicated (ignored) > uriah last message repeated 5 times > > ...73 of those silly messages are just beyond any form of usefulness. > Either we hide this completely behind bootverbose (back to the root of > this thread) since it bears no information at all (i already knew what > is written there, since it was my deliberate decision, and it could > not have happened unless being my deliberate decision), or we at least > ensure any of those messages is emitted at most once per drive. Hadn't we agreed to do this? I'm certainly in favour of the bootverbose approach. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
Ian Dowse wrote: > In message <[EMAIL PROTECTED]>, Peter Wemm writ es > : > >The problem is, that you **are** using fdisk tables, you have no choice. > >DD mode included a *broken* fdisk table that specified an illegal geometry. > ... > >This is why it is called dangerous. > > BTW, I presume you are aware of the way sysinstall creates DD MBRs; > it does not use the 5 sector slice 4 method, but sets up slice > 1 to cover the entire disk including the MBR, with c/h/s entries > corresponding to the real start and end of the disk, e.g: > > cylinders=3544 heads=191 sectors/track=53 (10123 blks/cyl) > ... > The data for partition 1 is: > sysid 165,(FreeBSD/NetBSD/386BSD) > start 0, size 35885168 (17522 Meg), flag 80 (active) > beg: cyl 0/ head 0/ sector 1; > end: cyl 1023/ head 190/ sector 53 > The data for partition 2 is: > > The data for partition 3 is: > > The data for partition 4 is: > > > Otherwise the disk layout is the same as disklabel's DD. I suspect > that this approach is much less illegal than disklabel's MBRs > although I do remember seeing a HP PC that disliked it. I wonder > if a reasonable compromise is to make disklabel use this system for > DD disks instead of the bogus 5 sector slice? Obviously, it > should also somehow not install a partition table unless boot1 is > being used as the MBR, and the fdisk -I method should be preferred. Yes, that is much safer, however there are certain bioses that have interesting quirks that the MBR has to work around. The problem when overlapping mbr and boot1 into the same block is that we no longer have the space to do that. boot1.s has got *3* bytes free. For example, we dont have space to fix the case where the drive number is passed through incorrectly to the mbr. Some older Intel boards have this problem (Phoenix derived bios). See boot0's setdrv option. Also (and I think this is more likely to be the problem you ran into) many newer PC's are looking at the partition tables for a suspend-to-disk partition or a FAT filesystem with a suspend-to-disk dump file. For better or worse, PC architecture dictates that boot disk partitions start and end on cylinder boundaries (except for the first one which starts on the second head in the first cylinder). When we break those rules, we have to be prepared for the consequences. However, there is light at the end of the tunnel. EFI GPT is pretty clean. It supports up to something like 16384 partitions and it has all the useful stuff we could possibly want including unique ID's, no CHS (pure 64 bit LBA), volume tags (you can name partitions etc), and so on. It is clean enough that we could almost get away with doing away with disklabel as well. "Coming soon to a PC near you." (http://developer.intel.com/technology/efi/index.htm) Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
On 09-Dec-01 Joerg Wunsch wrote: > As Peter Wemm wrote: > >> There shouldn't *be* bootblocks on non-boot disks. >> >> dd if=/dev/zero of=/dev/da$n count=1 >> >> Dont use "disklabel -B -rw da$n auto". Use "disklabel -rw da$n auto". > > All my disks have bootblocks and (spare) boot partitions. All the > bootblocks are DD mode. I don't see any point in using obsolete fdisk > tables. (There's IMHO only one purpose obsolete fdisk tables are good > for, co-operation with other operating systems in the same machine. > None of my machines uses anything else than FreeBSD.) Well, since they are a de facto part of the PC architecture they are also good so that you don't break BIOS's. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
:> Well, for reads a non-stripe-crossing op would still work reasonably :> well. But for writes less then full-stripe operations without :> spindle sync are going to be terrible due to the read-before-write :> requirement (to calculate parity). The disk cache is useless in that :> case. : :You obviously weren't reading the previous thread on RAID5 checksum :calculation, I see. 8) I don't see a thread on raid-5 checksuming. What was the subject? -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
> Well, for reads a non-stripe-crossing op would still work reasonably > well. But for writes less then full-stripe operations without > spindle sync are going to be terrible due to the read-before-write > requirement (to calculate parity). The disk cache is useless in that > case. You obviously weren't reading the previous thread on RAID5 checksum calculation, I see. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
:For RAID3 that is true. For the other ones...
:
:> performance without it - for reading OR writing. It doesn't matter
:> so much for RAID{1,10}, but it matters a whole lot for something like
:> RAID-5 where the difference between a spindle-synced read or write
:> and a non-spindle-synched read or write can be upwards of 35%.
:
:If you have RAID5 with I/O sizes that result in full-stripe operations.
:
:--
:| / o / /_ _email: [EMAIL PROTECTED]
:|/|/ / / /( (_) BulteArnhem, The Netherlands
Well, for reads a non-stripe-crossing op would still work reasonably
well. But for writes less then full-stripe operations without
spindle sync are going to be terrible due to the read-before-write
requirement (to calculate parity). The disk cache is useless in that
case.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
:> performance without it - for reading OR writing. It doesn't matter
:> so much for RAID{1,10}, but it matters a whole lot for something like
:> RAID-5 where the difference between a spindle-synced read or write
:> and a non-spindle-synched read or write can be upwards of 35%.
:
:If you have RAID5 with I/O sizes that result in full-stripe operations.
Well, 'more then one disk' operations anyway, for random-I/O. Caching
takes care of sequential I/O reasonably well but random-I/O goes down
the drain for writes if you aren't spindle synced, no matter what
the stripe size, and will go down the drain for reads if you cross
a stripe - something that is quite common I think.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
On Mon, Dec 10, 2001 at 10:13:20AM -0800, Matthew Dillon wrote:
> :Spindle sync is an anachronism these days; asynchronous behaviour
> :(write-behind in particular) is all the rage. You'd be hard-pressed to
> :find drives that even support it anymore.
>
> Woa! Say what? I think you are totally incorrect here Mike.
> Spindle sync is not an anachronism. You can't get good RAID{0,2,3,4,5}
For RAID3 that is true. For the other ones...
> performance without it - for reading OR writing. It doesn't matter
> so much for RAID{1,10}, but it matters a whole lot for something like
> RAID-5 where the difference between a spindle-synced read or write
> and a non-spindle-synched read or write can be upwards of 35%.
If you have RAID5 with I/O sizes that result in full-stripe operations.
--
| / o / /_ _ email: [EMAIL PROTECTED]
|/|/ / / /( (_) Bulte Arnhem, The Netherlands
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
:Spindle sync is an anachronism these days; asynchronous behaviour
:(write-behind in particular) is all the rage. You'd be hard-pressed to
:find drives that even support it anymore.
Woa! Say what? I think you are totally incorrect here Mike.
Spindle sync is not an anachronism. You can't get good RAID{0,2,3,4,5}
performance without it - for reading OR writing. It doesn't matter
so much for RAID{1,10}, but it matters a whole lot for something like
RAID-5 where the difference between a spindle-synced read or write
and a non-spindle-synched read or write can be upwards of 35%.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
> Joerg Wunsch wrote: > > > I guarantee you that there are a number of controllers which have > > > different ideas of how to do soft sector sparing _at the controller > > > level_ rather than at the drive level. > > > > We have dropped support for ESDI controllers long since. :-) > > > > Seriously, all the disks we are supporting these days do bad block > > replacement at the drive level. > > Adaptec 1742 is supported, though it took a long enough time to > find its way into CAM. Same for the NCR 810. Neither of which do controller-level sparing. > For certain applications, also, you _want_ to turn off the automatic > bad sector sparing: it's incompatible with spindle sync, for example, > where you want to spare all drives or none, so that the spindles don't > desyncronize on a sparing hit for one drive, but not another. Spindle sync is an anachronism these days; asynchronous behaviour (write-behind in particular) is all the rage. You'd be hard-pressed to find drives that even support it anymore. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
Joerg Wunsch wrote: > > I guarantee you that there are a number of controllers which have > > different ideas of how to do soft sector sparing _at the controller > > level_ rather than at the drive level. > > We have dropped support for ESDI controllers long since. :-) > > Seriously, all the disks we are supporting these days do bad block > replacement at the drive level. Adaptec 1742 is supported, though it took a long enough time to find its way into CAM. Same for the NCR 810. For certain applications, also, you _want_ to turn off the automatic bad sector sparing: it's incompatible with spindle sync, for example, where you want to spare all drives or none, so that the spindles don't desyncronize on a sparing hit for one drive, but not another. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
As Terry Lambert wrote: > Joerg Wunsch wrote: > > /The/ major advantage of DD mode was that all BIOSes (so far :) at > > least agree on how to access block 0 and the adjacent blocks, so > > starting our own system there makes those disks portable. > I guarantee you that there are a number of controllers which have > different ideas of how to do soft sector sparing _at the controller > level_ rather than at the drive level. We have dropped support for ESDI controllers long since. :-) Seriously, all the disks we are supporting these days do bad block replacement at the drive level. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
On Mon, Dec 10, 2001 at 11:04:38AM +0100, Joerg Wunsch wrote: > As Peter Wemm wrote: > > > Can you please clarify for me what specifically you do not like.. Is it: > > - the cost of 32K of disk space on an average disk these days? > > (and if so, is reducing that to one sector instead of 62 sufficient?) > > The idea of a "geometry" that does not even remotely resembles the > actual geometry and only causes additional hassles, like disks being > not portable between controllers that have a different idea of that > geometry (since the design of this table is missing an actual field > to specify the geometry). Incidentally, it's only what you call > "intuition" that finally stumpled across the 10-years old Jolitz > fake fdisk values. So IOW, it took the BIOS vendors ten years to > produce a BIOS that would break on it :), and the breakage (division > by 0) was only since they needed black magic in order to infer a > geometry value that was short-sightedly never specified in the table > itself. Two points to add why I would miss that feature: - Having bootable media such as MOs or zips. - There is no way to find out the BIOS geometry when creating a bootable disk inside FreeBSD. > > - you don't like typing "s1" in the device name? > > Aesthetically, yes, this one too. :) > > > "disklabel -rw ad2 auto" is one form. That should not use fdisk at all. > > This is quite fine, and nobody wants that to go away. > > Good to hear. > > Well, actually i always use "disklabel -Brw daN auto", partly because > this sequence is wired into my fingers, and since i mentally DAbelieve > that having more bootstrappable disks couldn't harm. ;-) As laid out > in another message, i eventually got the habit of even including a > root partition mirror on each disk as well. So each of my disks should > be able to boot a single-user FreeBSD. I was already happy to have them, but I can't create a propper bootable fdisk table without knowing what the BIOS thinks about geometry. It is the typical problem that you boot DOS, fdisk /mbr and then install FreeBSD... > > I advocate that the bootable form (where boot1.s is expected to do the > > job of both the mbr *and* the partition boot) is evil and should at the very > > least be fixed. > > Fixing is OK to me. I think to recognize the dummy fdisk table of DD mode, > it would be totally sufficient to verify slice 4 being labelled with 5 > blocks, and the other slices being labelled 0. We do not support any > physical disk anymore that is only 25 MB in size :). So all the remaining Flash Media comes in mind - but I hardly beleave it to be exactly 25M. > (INT 0x13 bootstrap) values could be anything -- even something that most > BIOSes would recognize as a valid fdisk table. > > > It should be something that is explicitly activated, and > > not something that you get whether you want it or not. > > I don't fully understand that. DD mode has always been an explicit > decision. Even in the above, the specification of -B explicitly tells > to install that bootstrap. The example in Handbook 12.3.2.2 should get the B flag removed. It's about adding disks and not about adding bootable disks. > As David O'Brien wrote: > > > > Its design is antique. Or rather: it's missing a design. > > > Jorg, why not just buy an Alpha or Sun Blade and run FreeBSD on it?? > > I don't see much value in an Alpha. Maybe a Sun some day, who knows? Not for the far future - but I would still prefer them over a PC. But my biggest hopes go for the UltraSparc port. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
In message <[EMAIL PROTECTED]>, Peter Wemm writes : >The problem is, that you **are** using fdisk tables, you have no choice. >DD mode included a *broken* fdisk table that specified an illegal geometry. ... >This is why it is called dangerous. BTW, I presume you are aware of the way sysinstall creates DD MBRs; it does not use the 5 sector slice 4 method, but sets up slice 1 to cover the entire disk including the MBR, with c/h/s entries corresponding to the real start and end of the disk, e.g: cylinders=3544 heads=191 sectors/track=53 (10123 blks/cyl) ... The data for partition 1 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 0, size 35885168 (17522 Meg), flag 80 (active) beg: cyl 0/ head 0/ sector 1; end: cyl 1023/ head 190/ sector 53 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: Otherwise the disk layout is the same as disklabel's DD. I suspect that this approach is much less illegal than disklabel's MBRs although I do remember seeing a HP PC that disliked it. I wonder if a reasonable compromise is to make disklabel use this system for DD disks instead of the bogus 5 sector slice? Obviously, it should also somehow not install a partition table unless boot1 is being used as the MBR, and the fdisk -I method should be preferred. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
As Peter Wemm wrote: > Can you please clarify for me what specifically you do not like.. Is it: > - the cost of 32K of disk space on an average disk these days? > (and if so, is reducing that to one sector instead of 62 sufficient?) The idea of a "geometry" that does not even remotely resembles the actual geometry and only causes additional hassles, like disks being not portable between controllers that have a different idea of that geometry (since the design of this table is missing an actual field to specify the geometry). Incidentally, it's only what you call "intuition" that finally stumpled across the 10-years old Jolitz fake fdisk values. So IOW, it took the BIOS vendors ten years to produce a BIOS that would break on it :), and the breakage (division by 0) was only since they needed black magic in order to infer a geometry value that was short-sightedly never specified in the table itself. > - you don't like typing "s1" in the device name? Aesthetically, yes, this one too. :) > "disklabel -rw ad2 auto" is one form. That should not use fdisk at all. > This is quite fine, and nobody wants that to go away. Good to hear. Well, actually i always use "disklabel -Brw daN auto", partly because this sequence is wired into my fingers, and since i mentally DAbelieve that having more bootstrappable disks couldn't harm. ;-) As laid out in another message, i eventually got the habit of even including a root partition mirror on each disk as well. So each of my disks should be able to boot a single-user FreeBSD. > I advocate that the bootable form (where boot1.s is expected to do the > job of both the mbr *and* the partition boot) is evil and should at the very > least be fixed. Fixing is OK to me. I think to recognize the dummy fdisk table of DD mode, it would be totally sufficient to verify slice 4 being labelled with 5 blocks, and the other slices being labelled 0. We do not support any physical disk anymore that is only 25 MB in size :). So all the remaining (INT 0x13 bootstrap) values could be anything -- even something that most BIOSes would recognize as a valid fdisk table. > It should be something that is explicitly activated, and > not something that you get whether you want it or not. I don't fully understand that. DD mode has always been an explicit decision. Even in the above, the specification of -B explicitly tells to install that bootstrap. As David O'Brien wrote: > > Its design is antique. Or rather: it's missing a design. > Jorg, why not just buy an Alpha or Sun Blade and run FreeBSD on it?? I don't see much value in an Alpha. Maybe a Sun some day, who knows? As i understand it now, the UltraSparc port is not quite at that stage, but i'm willing to experiment with it when i find a bit of time and documentation how to get started. I've got access to a good number of Suns here at work, and i think there are even a number of colleagues who would prefer FreeBSD over Solaris on them. If FreeBSD would had been ready for it, i could have tested it on the new V880 machine that was just announced recently. :) (We were the first one worldwide to show it on a fair trade here, about 24 hours after the official announcment...) -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
Ah, the thread which would not die... 8^). Joerg Wunsch wrote: > /The/ major advantage of DD mode was that all BIOSes (so far :) at > least agree on how to access block 0 and the adjacent blocks, so > starting our own system there makes those disks portable. I guarantee you that there are a number of controllers which have different ideas of how to do soft sector sparing _at the controller level_ rather than at the drive level. Disks created with such controllers aren't portable, since they depend on controller state information, which may not be valid from controller to controller, depending on the controller settings (I killed a disk by not having the WD1007 soft sector sparing jumper set the same in the machine I put it in as in the machine I took it out of... 8^)). > I've read this, and yes, i never argued about fixing /that/. Since > those values chosen by our grandfather Bill Jolitz have been just > `magic' numbers only, it's unfortunate they eventually turned out to > be such bad magic about a decade later. Yeah, we should pick new magic. It's bound to die again in the future, though, once "what's magic" changes out from under us again... 8^(. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
As Peter Wemm wrote: > No, it isn't ignored, BIOS'es "know" that fdisk partitions end on > cylinder boundaries, and therefore can intuit what the expected > geometry is for the disk in question. And you call that a "design"? I call it a poor hack, nothing else. The restriction to whatever the BIOS believes to be a "cylinder" boundary is one of my gripes with fdisk tables; you obviously missed that (or you don't argue about it -- can i take this as silent agreement?). It imposes a geometry that is not even remotely there, with the drawbacks that a number of sectors can never be assigned (OK, no big deal these days), but even worse, disks are non-portable between different BIOSes that perform different "intuition" about how to obtain the "geometry" from those poorly chosen values that are included in fdisk tables. /The/ major advantage of DD mode was that all BIOSes (so far :) at least agree on how to access block 0 and the adjacent blocks, so starting our own system there makes those disks portable. > [...] The problem is that the int13 code only allowed for 255 heads, > and the fake "end of disk" entry that is unconditionally in /boot/boot1 > specified an ending head number 255 (ie: 256 heads). When this gets put > into a byte register it is truncated to zero and we get divide by zero > errors. I've read this, and yes, i never argued about fixing /that/. Since those values chosen by our grandfather Bill Jolitz have been just `magic' numbers only, it's unfortunate they eventually turned out to be such bad magic about a decade later. > We can just as easily have bootable-DD mode with a real MBR and have > freebsd start on sector #2 instead of overlapping boot1 and mbr. Probably, i think i could live with that. > I'd rather that we be specific about this. If somebody wants ad2e > or da2e then they should not be using *any* fdisk tables at all. > Ie: block 0 should be empty. That disk wouldn't boot at all, you know that. Yes, i prefer my disks to be called da0a...daNP. >> But to be honest, see my other article: i never argued to make this >> the default or a recommended strategy in any form. It should only >> remain intact at all. Back to the subject, the current warning >> however, is pointless, and has the major drawback to potentially >> hide important console messages. > The console buffer is 32K these days. You'd have to have around 300 > disks to have any real effect on the kernel. You're narrow minded here, Peter, this time about in the same way as Windoze is narrow minded: "All the world's a graphical console produced by XXX." No, all the world's not like that. You might consider my pcvt console obsolete, OK, but did you ever think about a plain VT220 on a serial console? They don't have /any/ scrollback buffer. (And you can't even stop the output with ^S while FreeBSD is booting.) Also, i think that: uriah /boot/kernel/kernel: da0: invalid primary partition table: Dangerously Dedicated (ignored) uriah last message repeated 5 times uriah /boot/kernel/kernel: da1: invalid primary partition table: Dangerously Dedicated (ignored) uriah last message repeated 34 times uriah /boot/kernel/kernel: da2: invalid primary partition table: Dangerously Dedicated (ignored) uriah last message repeated 34 times ...73 of those silly messages are just beyond any form of usefulness. Either we hide this completely behind bootverbose (back to the root of this thread) since it bears no information at all (i already knew what is written there, since it was my deliberate decision, and it could not have happened unless being my deliberate decision), or we at least ensure any of those messages is emitted at most once per drive. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
Joerg Wunsch wrote: > Mike Smith <[EMAIL PROTECTED]> wrote: > > > - The MBR partition table is not "obsolete", it's a part of the PC > >architecture specification. > > Its design is antique. Or rather: it's missing a design. See other > mail for the reasons. For FreeBSD, it's obsolete since we don't need > to rely on fdisk slices. (Or rather: it's optional. We can make good > use of it when it's there, but we don't need to insist on it being > there.) Can you please clarify for me what specifically you do not like.. Is it: - the cost of 32K of disk space on an average disk these days? (and if so, is reducing that to one sector instead of 62 sufficient?) - you don't like typing "s1" in the device name? Dont forget, there is quite a bit of confusion about what "DD" means. "disklabel -rw ad2 auto" is one form. That should not use fdisk at all. This is quite fine, and nobody wants that to go away. But the abomination is the form that is pseudo-bootable. We fill up boot1.s with a fake fdisk table and crap to try and work around cases where we are called either as the partition boot sector, or as a global MBR. This one should be taken out and shot. If you are going to make a bootable disk, you had better play by the rules of the environment that is booting it. At the very least, the fdisk table should be valid! I advocate that the bootable form (where boot1.s is expected to do the job of both the mbr *and* the partition boot) is evil and should at the very least be fixed. It should be something that is explicitly activated, and not something that you get whether you want it or not. This would have solved the Thinkpad and does solve the EFI problem. There are lots of ways that it can be fixed without forcing an "s1" into your device names if that's what is really upsetting you. > As long as you keep the feature of DD mode intact, i won't argue. If > people feel like creating disks that aren't portable to another > controller, they should do. I don't like this idea. Which "DD" mode? Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
On Sun, Dec 09, 2001 at 11:00:19PM +0100, Joerg Wunsch wrote: > Mike Smith <[EMAIL PROTECTED]> wrote: > > - The MBR partition table is not "obsolete", it's a part of the PC > >architecture specification. > > Its design is antique. Or rather: it's missing a design. See other > mail for the reasons. For FreeBSD, it's obsolete since we don't need > to rely on fdisk slices. (Or rather: it's optional. We can make good > use of it when it's there, but we don't need to insist on it being > there.) Jorg, why not just buy an Alpha or Sun Blade and run FreeBSD on it?? You will get the traditional Unix workstation partitioning you so much long for. It really seems your arguments are nothing more than "MBR's are a M$ and IBM PeeCee thing, and I hate anything PeeCee". To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
> Joerg Wunsch wrote: > > Mike Smith <[EMAIL PROTECTED]> wrote: > > > - The MBR partition table is not "obsolete", it's a part of the PC > > >architecture specification. > > > > Its design is antique. Or rather: it's missing a design. See other > > mail for the reasons. For FreeBSD, it's obsolete since we don't need > > to rely on fdisk slices. (Or rather: it's optional. We can make good > > use of it when it's there, but we don't need to insist on it being > > there.) FWIW: The MBR layout is documented in great gory detail in chapter 6 of the PReP specififcation, which I believe is now available on line from the PowerPC folks, Apple, and Motorolla, and also as an IBM "redbook". It discusses everything, including the LBA fields, and sharing disks between PPC (running in Motorolla byte order) and x86 machines (running a DOS-derived OS). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
Joerg Wunsch wrote: > Mike Smith <[EMAIL PROTECTED]> wrote: > > > - The MBR partition table is not "obsolete", it's a part of the PC > >architecture specification. > > Its design is antique. Or rather: it's missing a design. See other > mail for the reasons. For FreeBSD, it's obsolete since we don't need > to rely on fdisk slices. (Or rather: it's optional. We can make good > use of it when it's there, but we don't need to insist on it being > there.) No, it isn't. We specifically have a copy of both the broken and fixed fdisk tables in the kernel and do a bcmp() to see if the fdisk table that is included in /boot/boot1 **uncoditionally** is in fact the dangerously dedicated table. If it is, then we specifically reject it or we end up with a disk size of 25MB (5 sectors). > > You do realise that "DD" mode does include a (invalid) MBR partition > > table (now valid, courtesy of a long-needed fix), right? > > Yes, of course, one that is basically ignored by everything. It has > always been there, back since 386BSD 0.1. 386BSD 0.0 didn't recognize > fdisk tables at all, but could only live on a disk by its own (as any > other BSD before used to). No, it isn't ignored, BIOS'es "know" that fdisk partitions end on cylinder boundaries, and therefore can intuit what the expected geometry is for the disk in question. It does this in order to allow the CHS int 0x13 calls to work. The problem is that the int13 code only allowed for 255 heads, and the fake "end of disk" entry that is unconditionally in /boot/boot1 specified an ending head number 255 (ie: 256 heads). When this gets put into a byte register it is truncated to zero and we get divide by zero errors. > > I'd love to never hear those invalid, unuseful, misleading opinions > > from you again. > > ETOOMANYATTRIBUTES? :-) > > As long as you keep the feature of DD mode intact, i won't argue. If > people feel like creating disks that aren't portable to another > controller, they should do. I don't like this idea. We can just as easily have bootable-DD mode with a real MBR and have freebsd start on sector #2 instead of overlapping boot1 and mbr. This costs only one sector instead of 64 sectors (a whopping 32K, I'm sure that is going to break the bank on today's disks). I'd rather that we be specific about this. If somebody wants ad2e or da2e then they should not be using *any* fdisk tables at all. Ie: block 0 should be empty. The problem is that if you put /boot/boot1 in there, then suddenly it looks like a fdisk disk and we have to have ugly magic to detect it and prevent the fake table from being used. I would prefer that the fdisk table come out of /boot/boot1 so that we dont have to have it by default, and we use fdisk to install the "DD magic table" if somebody wants to make it bootable. > But to be honest, see my other article: i never argued to make this > the default or a recommended strategy in any form. It should only > remain intact at all. Back to the subject, the current warning > however, is pointless, and has the major drawback to potentially hide > important console messages. The console buffer is 32K these days. You'd have to have around 300 disks to have any real effect on the kernel. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
:This illegal geometry causes divide by zero errors in a handful of scsi :bioses from Adaptec. : :This illegal geometry causes divide by zero errors in a handful of scsi :bioses from NCR/Symbios. : :This is why it is called dangerous. : :Cheers, :-Peter :-- :Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Handful? I'm taking my life in my hands if I DD a DELL machine. BEWM! As I found out the hard way about a year ago. (Probably the Adaptec firmware but every Dell rack-mount has one so...). The machines wouldn't boot again until I pulled the physical drives and then camcontrol rescan'd them in after a CD boot. Joy. This is why I fixed disklabel -B to operate properly on slices and added a whole section to the end of 'man disklabel' to describe how to do it. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
Joerg Wunsch wrote: > As Peter Wemm wrote: > > > There shouldn't *be* bootblocks on non-boot disks. > > > > dd if=/dev/zero of=/dev/da$n count=1 > > > > Dont use "disklabel -B -rw da$n auto". Use "disklabel -rw da$n auto". > > All my disks have bootblocks and (spare) boot partitions. All the > bootblocks are DD mode. I don't see any point in using obsolete fdisk > tables. (There's IMHO only one purpose obsolete fdisk tables are good > for, co-operation with other operating systems in the same machine. > None of my machines uses anything else than FreeBSD.) The problem is, that you **are** using fdisk tables, you have no choice. DD mode included a *broken* fdisk table that specified an illegal geometry. This illegal geometry was the reason why Thinkpad Laptops would wedge solid when you installed FreeBSD on it. This illegal geometry is the reason why FreeBSD disks wedge solid any EFI system unless you remove the illegal geometry tables. This illegal geometry causes divide by zero errors in a handful of scsi bioses from Adaptec. This illegal geometry causes divide by zero errors in a handful of scsi bioses from NCR/Symbios. This is why it is called dangerous. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
Mike Smith <[EMAIL PROTECTED]> wrote: > - The MBR partition table is not "obsolete", it's a part of the PC >architecture specification. Its design is antique. Or rather: it's missing a design. See other mail for the reasons. For FreeBSD, it's obsolete since we don't need to rely on fdisk slices. (Or rather: it's optional. We can make good use of it when it's there, but we don't need to insist on it being there.) > You do realise that "DD" mode does include a (invalid) MBR partition > table (now valid, courtesy of a long-needed fix), right? Yes, of course, one that is basically ignored by everything. It has always been there, back since 386BSD 0.1. 386BSD 0.0 didn't recognize fdisk tables at all, but could only live on a disk by its own (as any other BSD before used to). > I'd love to never hear those invalid, unuseful, misleading opinions > from you again. ETOOMANYATTRIBUTES? :-) As long as you keep the feature of DD mode intact, i won't argue. If people feel like creating disks that aren't portable to another controller, they should do. I don't like this idea. But to be honest, see my other article: i never argued to make this the default or a recommended strategy in any form. It should only remain intact at all. Back to the subject, the current warning however, is pointless, and has the major drawback to potentially hide important console messages. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
> (The other day a coworker of mine wanted to use DD for some IBM DTLA > disks, because he'd heard that the disks performed better that way - > something to do with scatter-gather not working right unless you used > DD. I'm highly skeptical about this since I have my own measurements > from IBM DTLA disks partitioned the normal way, ie. NOT DD, and they > show the disks performing extremely well. Anybody else want to comment > on this?) Since scatter-gather has nothing to do with the disk (it's a feature of the disk controller's interface to host memory), I think this coworker of yours is delusional. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
> As Peter Wemm wrote: > > > There shouldn't *be* bootblocks on non-boot disks. > > > > dd if=/dev/zero of=/dev/da$n count=1 > > > > Dont use "disklabel -B -rw da$n auto". Use "disklabel -rw da$n auto". > > All my disks have bootblocks and (spare) boot partitions. All the > bootblocks are DD mode. I don't see any point in using obsolete fdisk > tables. (There's IMHO only one purpose obsolete fdisk tables are good > for, co-operation with other operating systems in the same machine. > None of my machines uses anything else than FreeBSD.) Since I tire of seeing people hit this ignorant opinion in the list archives, I'll just offer the rational counterpoints. - The MBR partition table is not "obsolete", it's a part of the PC architecture specification. - You omit the fact that many peripheral device vendors' BIOS code looks for the MBR partition table, and will fail if it's not present or incorrect. You do realise that "DD" mode does include a (invalid) MBR partition table (now valid, courtesy of a long-needed fix), right? I'd love to never hear those invalid, unuseful, misleading opinions from you again. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
As [EMAIL PROTECTED] wrote: > There are very good reasons NOT to use DD mode if you use certain > types of Adaptec SCSI controllers - they simply won't boot from DD. Never seen. All my SCSI controllers so far booted from my disks (obviously :). I figure from Peter's comment in that piece of code that the original (386BSD 0.0 inherited) DD mode fake fdisk table apparently had some poor (faked) values inside that could upset some BIOSes. That's bad, and IMHO we should fix what could be fixed, but without dropping that feature entirely (see below). Still, it's my opinion that these BIOSes are simply broken: interpretation of the fdisk table has always been in the realm of the boot block itself. The BIOS should decide whether a disk is bootable or not by looking at the 0x55aa signature at the end, nothing else. Think of the old OnTrack Disk Manager that extended the fdisk table to 16 slots -- nothing the BIOS could ever even handle. It was in the realm of the boot block to interpret it. > Aside from that, FreeBSD needs to have *one* recommendation for > disks, anything else creates too much confusion. DD mode has never been a recommendation. It is for those who know what it means. I'm only against the idea to silently drop support for it... fdisk tables are something that has been designed in the previous millenium, and i think nobody is going to argue about it that they are rather a mis-design from the beginning (or even no design at all, but an ad-hoc implementation). Two different values for the same (which could become conflicting, thus making disks unportable between different controllers), not enough value space to even remotely cover the disks of our millenium, enforcement of something they call `geometry' which isn't even remotely related to the disks' geometry anymore at all, far too few possible entries anyway, ... FreeBSD is in a position where it doesn't strictly require the existence of such an obsoleted implementation detail, so we should users leave the freedom of decision. Again, it has never been the recommendation (well, at least not after 386BSD 0.0 :), and i normally wouldn't recommend it to the innocent user. But we should not break it either. > (The other day a coworker of mine wanted to use DD for some IBM DTLA > disks, because he'd heard that the disks performed better that way - > something to do with scatter-gather not working right unless you > used DD. [...]) As much as i personally prefer DD mode: that's an urban legend. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
As Daniel O'Connor wrote: > I don't understand the need some people have for using something > that is labelled as DANGEROUS. Historically, it hasn't been labelled that, it only later became common terminology for it -- in the typical half-joking manner. > No, it won't hurt your cats but you may lose hair from using it, and > for what benefit? NONE! See my other reply about fdisk tables: they are a misdesign from the beginning. The single most wanted feature it buys you is the ability to completely forget the term `geometry' with your disks: the very first sectors of a disk always have the same BIOS int 0x13 representation, regardless of what your BIOS/controller thinks the `geometry' might be. Thus, those disks are basically portable between controller BIOSes. (Modulo those newer broken BIOSes that believe eggs must be smarter than hens -- see my other article for an opinion.) -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
On 09-Dec-2001 [EMAIL PROTECTED] wrote: > (The other day a coworker of mine wanted to use DD for some IBM DTLA > disks, because he'd heard that the disks performed better that way - > something to do with scatter-gather not working right unless you used > DD. I'm highly skeptical about this since I have my own measurements > from IBM DTLA disks partitioned the normal way, ie. NOT DD, and they > show the disks performing extremely well. Anybody else want to comment > on this?) Sounds like an Old Wives Tale to me. I don't understand the need some people have for using something that is labelled as DANGEROUS. No, it won't hurt your cats but you may lose hair from using it, and for what benefit? NONE! --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
> All my disks have bootblocks and (spare) boot partitions. All the > bootblocks are DD mode. I don't see any point in using obsolete fdisk > tables. (There's IMHO only one purpose obsolete fdisk tables are good > for, co-operation with other operating systems in the same machine. > None of my machines uses anything else than FreeBSD.) There are very good reasons NOT to use DD mode if you use certain types of Adaptec SCSI controllers - they simply won't boot from DD. Aside from that, FreeBSD needs to have *one* recommendation for disks, anything else creates too much confusion. It is certainly my impression that the recommendation has been NOT using DD for the IA32 architecture for quite a while now. (The other day a coworker of mine wanted to use DD for some IBM DTLA disks, because he'd heard that the disks performed better that way - something to do with scatter-gather not working right unless you used DD. I'm highly skeptical about this since I have my own measurements from IBM DTLA disks partitioned the normal way, ie. NOT DD, and they show the disks performing extremely well. Anybody else want to comment on this?) Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
As Peter Wemm wrote: > There shouldn't *be* bootblocks on non-boot disks. > > dd if=/dev/zero of=/dev/da$n count=1 > > Dont use "disklabel -B -rw da$n auto". Use "disklabel -rw da$n auto". All my disks have bootblocks and (spare) boot partitions. All the bootblocks are DD mode. I don't see any point in using obsolete fdisk tables. (There's IMHO only one purpose obsolete fdisk tables are good for, co-operation with other operating systems in the same machine. None of my machines uses anything else than FreeBSD.) -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
On Sat, Dec 08, 2001 at 05:09:11PM -0800, Peter Wemm wrote: > Joerg Wunsch wrote: > > Bernd Walter <[EMAIL PROTECTED]> wrote: > > > > > 32 times for each disk on booting with most of 30 disks. > > > Possibly it's triggered by vinums drive scanning. > > > > Yep, same here (and it is triggered by vinum). > > > > > What can I do about these messages? > > > > Remove it. It should not have been there in the first place, at least > > not without an "if (bootverbose) ..." in front of it. It isn't > > telling any news anyway, because you certainly already knew that your > > disks are using DD mode, and the last word is telling "(ignored)" > > which is the intented and expected action to happen anyway. > > There shouldn't *be* bootblocks on non-boot disks. I usually have a /boot/loader.work and a /boot/kernel.work for updating. What is wrong about having spare bootblocks? In fact I already needed them twice and the diskspace is unused anyway. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
Joerg Wunsch wrote: > Bernd Walter <[EMAIL PROTECTED]> wrote: > > > 32 times for each disk on booting with most of 30 disks. > > Possibly it's triggered by vinums drive scanning. > > Yep, same here (and it is triggered by vinum). > > > What can I do about these messages? > > Remove it. It should not have been there in the first place, at least > not without an "if (bootverbose) ..." in front of it. It isn't > telling any news anyway, because you certainly already knew that your > disks are using DD mode, and the last word is telling "(ignored)" > which is the intented and expected action to happen anyway. There shouldn't *be* bootblocks on non-boot disks. dd if=/dev/zero of=/dev/da$n count=1 Dont use "disklabel -B -rw da$n auto". Use "disklabel -rw da$n auto". Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
:boot block itself). The comments tell a bit more about it. But :adding pointless messages that flush the boot log and possibly hide :important boot messages can't be goo. : :-- :cheers, J"org .-.-. --... ...-- -.. . DL8DTL Yes, Goo in the computer is wery, wery bad! -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
Bernd Walter <[EMAIL PROTECTED]> wrote: > 32 times for each disk on booting with most of 30 disks. > Possibly it's triggered by vinums drive scanning. Yep, same here (and it is triggered by vinum). > What can I do about these messages? Remove it. It should not have been there in the first place, at least not without an "if (bootverbose) ..." in front of it. It isn't telling any news anyway, because you certainly already knew that your disks are using DD mode, and the last word is telling "(ignored)" which is the intented and expected action to happen anyway. I do understand Peters gripe about broken BIOSes that try to interpret fdisk tables (where the fdisk table is actually in the domain of the boot block itself). The comments tell a bit more about it. But adding pointless messages that flush the boot log and possibly hide important boot messages can't be goo. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/kern subr_diskmbr.c
On Wed, Nov 21, 2001 at 12:31:45AM -0800, Peter Wemm wrote: > peter 2001/11/21 00:31:45 PST > > Modified files: > sys/kern subr_diskmbr.c > Log: > Recognize the "fixed" geometry in boot1 so that DD disks are not > interpreted as real fdisk tables (and fail). > > Revision ChangesPath > 1.53 +31 -6 src/sys/kern/subr_diskmbr.c Maybe I'm a bit late with this subject. I have updated a machine yesterday and get these messages: da28: invalid primary partition table: Dangerously Dedicated (ignored) 32 times for each disk on booting with most of 30 disks. Possibly it's triggered by vinums drive scanning. OK it was unneeded to install bootblocks on dedicated disks other than the boot device, but it's a lot of noise for that. What can I do about these messages? -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
