Re: "Dangerously Decidated" yet again (was : cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-13 Thread Holger Kipp
On Mon, Dec 10, 2001 at 07:27:09PM +1030, Greg Lehey wrote: > suggests, that this is a fixable bug, but every time I mention it, I > get shouted down. And yes, like Jörg, I don't care enough. I'm not > saying "ditch the Microsoft partition table", I'm saying "don't ditch > disks without the Mic

Re: Vinum write performance (was: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c))

2001-12-12 Thread Bernd Walter
On Thu, Dec 13, 2001 at 12:47:53PM +1030, Greg Lehey wrote: > On Thursday, 13 December 2001 at 3:06:14 +0100, Bernd Walter wrote: > > Currently if we have two writes in two stripes each, all initated before > > the first finished, the drive has to seek between the two stripes, as > > the second w

Re: Vinum write performance (was: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c))

2001-12-12 Thread Greg Lehey
On Thursday, 13 December 2001 at 3:06:14 +0100, Bernd Walter wrote: > On Thu, Dec 13, 2001 at 10:54:13AM +1030, Greg Lehey wrote: >> On Wednesday, 12 December 2001 at 12:53:37 +0100, Bernd Walter wrote: >>> On Wed, Dec 12, 2001 at 04:22:05PM +1030, Greg Lehey wrote: On Tuesday, 11 December 2

Re: Vinum write performance (was: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c))

2001-12-12 Thread Bernd Walter
On Thu, Dec 13, 2001 at 10:54:13AM +1030, Greg Lehey wrote: > On Wednesday, 12 December 2001 at 12:53:37 +0100, Bernd Walter wrote: > > On Wed, Dec 12, 2001 at 04:22:05PM +1030, Greg Lehey wrote: > >> On Tuesday, 11 December 2001 at 3:11:21 +0100, Bernd Walter wrote: > >> 2. Cache the parity blo

Re: Vinum write performance (was: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c))

2001-12-12 Thread Greg Lehey
On Wednesday, 12 December 2001 at 12:53:37 +0100, Bernd Walter wrote: > On Wed, Dec 12, 2001 at 04:22:05PM +1030, Greg Lehey wrote: >> On Tuesday, 11 December 2001 at 3:11:21 +0100, Bernd Walter wrote: >>> striped: >>> If you have 512byte stripes and have 2 disks. >>> You access 64k which is put

Re: Vinum write performance (was: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c))

2001-12-12 Thread Bernd Walter
On Wed, Dec 12, 2001 at 04:22:05PM +1030, Greg Lehey wrote: > On Tuesday, 11 December 2001 at 3:11:21 +0100, Bernd Walter wrote: > > striped: > > If you have 512byte stripes and have 2 disks. > > You access 64k which is put into 2 32k transactions onto the disk. > > Only if your software optimiz

Re: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-11 Thread Greg Lehey
On Tuesday, 11 December 2001 at 23:41:51 +0100, Wilko Bulte wrote: > On Wed, Dec 12, 2001 at 09:00:34AM +1030, Greg Lehey wrote: >> On Tuesday, 11 December 2001 at 15:34:37 +0100, Wilko Bulte wrote: >>> On Tue, Dec 11, 2001 at 11:06:33AM +1030, Greg Lehey wrote: On Monday, 10 December 2001 at

Vinum write performance (was: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c))

2001-12-11 Thread Greg Lehey
On Tuesday, 11 December 2001 at 3:11:21 +0100, Bernd Walter wrote: > On Tue, Dec 11, 2001 at 11:06:33AM +1030, Greg Lehey wrote: >> On Monday, 10 December 2001 at 10:30:04 -0800, Matthew Dillon wrote: >>> > performance without it - for reading OR writing. It doesn't matter > so m

Re: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-11 Thread Wilko Bulte
On Wed, Dec 12, 2001 at 09:00:34AM +1030, Greg Lehey wrote: > On Tuesday, 11 December 2001 at 15:34:37 +0100, Wilko Bulte wrote: > > On Tue, Dec 11, 2001 at 11:06:33AM +1030, Greg Lehey wrote: > >> On Monday, 10 December 2001 at 10:30:04 -0800, Matthew Dillon wrote: > >>> .. > >>> and will g

Re: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-11 Thread Greg Lehey
On Tuesday, 11 December 2001 at 15:34:37 +0100, Wilko Bulte wrote: > On Tue, Dec 11, 2001 at 11:06:33AM +1030, Greg Lehey wrote: >> On Monday, 10 December 2001 at 10:30:04 -0800, Matthew Dillon wrote: >>> > performance without it - for reading OR writing. It doesn't matter > so mu

Re: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-11 Thread Bernd Walter
On Tue, Dec 11, 2001 at 03:34:37PM +0100, Wilko Bulte wrote: > On Tue, Dec 11, 2001 at 11:06:33AM +1030, Greg Lehey wrote: > > I think this is what Mike was referring to when talking about parity > > calculation. In any case, going across a stripe boundary is not a > > good idea, though of course

Re: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-11 Thread Wilko Bulte
On Tue, Dec 11, 2001 at 11:06:33AM +1030, Greg Lehey wrote: > On Monday, 10 December 2001 at 10:30:04 -0800, Matthew Dillon wrote: > > > >>> 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 > >>

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-10 Thread Joerg Wunsch
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. To

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-10 Thread Bernd Walter
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 wher

Re: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-10 Thread Bernd Walter
On Tue, Dec 11, 2001 at 11:06:33AM +1030, Greg Lehey wrote: > On Monday, 10 December 2001 at 10:30:04 -0800, Matthew Dillon wrote: > > > >>> 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 > >>

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-10 Thread Greg Lehey
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 usefu

"Dangerously Dedicated" (was: cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-10 Thread Greg Lehey
On Sunday, 9 December 2001 at 16:59:28 -0800, Peter Wemm wrote: > Joerg Wunsch wrote: >> Mike Smith <[EMAIL PROTECTED]> wrote: >>> 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

RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-10 Thread Greg Lehey
On Monday, 10 December 2001 at 10:30:04 -0800, Matthew Dillon wrote: > >>> 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 wri

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-10 Thread Peter Wemm
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

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-10 Thread John Baldwin
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.

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-10 Thread Matthew Dillon
:> 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

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-10 Thread Mike Smith
> 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 >

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-10 Thread Matthew Dillon
: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-spi

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-10 Thread Matthew Dillon
:> 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%.

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-10 Thread Wilko Bulte
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 t

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-10 Thread Matthew Dillon
: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 c

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-10 Thread Mike Smith
> 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. :-) > > > > Seriou

Re: "Dangerously Decidated" yet again (was : cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-10 Thread Mike Smith
> What is it about this particular topic brings out such irrational > emotions in you and others? Because you define as "irrational" those opinions that don't agree with your own. I don't consider my stance "irrational" at all, and I find your leaps past logic and commonsense quite "irrational

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-10 Thread Terry Lambert
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 dis

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-10 Thread Joerg Wunsch
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 con

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-10 Thread Bernd Walter
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 suf

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-10 Thread Ian Dowse
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 cr

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-10 Thread Joerg Wunsch
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 resemble

Re: "Dangerously Decidated" yet again (was : cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-10 Thread Terry Lambert
Greg Lehey wrote: > What is it about this particular topic brings out such irrational > emotions in you and others? Everyone who has been around for any length of time has been bitten on the arse by it at one time or another, I think. I remember Alfred made a "Lapbrick" out of a system a while b

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-10 Thread Terry Lambert
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 numb

Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-10 Thread Terry Lambert
"David W. Chapman Jr." wrote: > > > :> > IBM DTLA drives are known to rotate fast enough near the spindle > > > :> > that the sustained write speed exceeds the ability of the controller > > > :> > electronics to keep up, and results in crap being written to disk. > > > > > > I would adssume it act

Re: "Dangerously Decidated" yet again (was : cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-10 Thread Greg Lehey
On Monday, 10 December 2001 at 0:17:14 -0800, Mike Smith wrote: > Still, it's my opinion that these BIOSes are simply broken: >>> >>> Joerg's personal opinion can go take a hike. The reality of the >>> situation is that this table is required, and we're going to put it there. >> >> The reali

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-10 Thread Joerg Wunsch
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

Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-10 Thread Matthew Dillon
:> Wouldn't the linear speed be faster closer to the spindle at 7200 RPM :> than at the edge? : :The stunning ignorance being displayed in this thread appears to have :reached an all-time low. : :*sigh* Ah, another poor soul who didn't read the first sentence of tuning(7).

Re: "Dangerously Decidated" yet again (was : cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-10 Thread Mike Smith
> >>> Still, it's my opinion that these BIOSes are simply broken: > > > > Joerg's personal opinion can go take a hike. The reality of the > > situation is that this table is required, and we're going to put it there. > > The reality of the situation is far from being clear. The only thing > I c

Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-10 Thread Mike Smith
> > > :> > IBM DTLA drives are known to rotate fast enough near the spindle > > > :> > that the sustained write speed exceeds the ability of the controller > > > :> > electronics to keep up, and results in crap being written to disk. > > > > I would adssume it actually the tracks FURTHEREST from

IBM DTLA drives (was: Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c) )

2001-12-09 Thread Peter Wemm
Matthew Dillon wrote: > :> etc... So apparently my warning about these drives in 'man tuning' is > :> still appropriate :-) > :> > :>-Matt > :> > :> :> > IBM DTLA drives are known to rotate fast enough near the spindle > :> :> > that the sustained wri

Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-09 Thread Greg Lehey
On Sunday, 9 December 2001 at 22:44:52 -0800, Peter Wemm wrote: > 3) You get a system lockup when booting the *computer* if *any* DD disk >is attached anywhere at all. This is what killed the Thinkpad T20*, >A20*, 600X etc. After all the yelling we did at IBM, it turned out >to be F

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-09 Thread Peter Wemm
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 s

Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-09 Thread Andrew Kenneth Milton
+---[ David W. Chapman Jr. ]-- | > > :> > IBM DTLA drives are known to rotate fast enough near the spindle | > > :> > that the sustained write speed exceeds the ability of the controller | > > :> > electronics to keep up, and results in crap being written to disk. | > | >

Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-09 Thread Peter Wemm
"David W. Chapman Jr." wrote: > On Sun, Dec 09, 2001 at 06:46:24PM -0800, Terry Lambert wrote: > > It's because you have to reinstall, should you want to add a second > > OS at a later date (e.g. Linux, or Windows). > > I think it has more to do with the drive going on a new motherboard > that m

Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-09 Thread Peter Wemm
"David W. Chapman Jr." wrote: > > > :> > IBM DTLA drives are known to rotate fast enough near the spindle > > > :> > that the sustained write speed exceeds the ability of the controller > > > :> > electronics to keep up, and results in crap being written to disk. > > > > > > I would adssume it a

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-09 Thread David O'Brien
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

Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-09 Thread David W. Chapman Jr.
> > :> > IBM DTLA drives are known to rotate fast enough near the spindle > > :> > that the sustained write speed exceeds the ability of the controller > > :> > electronics to keep up, and results in crap being written to disk. > > > I would adssume it actually the tracks FURTHEREST from the spi

Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-09 Thread Matthew Dillon
On google search for: deskstar 75gxp class action http://www.theregister.co.uk/content/54/22412.html http://www.pcworld.com/news/article/0,aid,67608,00.asp etc... So apparently my warning about these drives in 'man tuning' is still appropriate :-)

Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-09 Thread Terry Lambert
"David W. Chapman Jr." wrote: > On Sun, Dec 09, 2001 at 06:46:24PM -0800, Terry Lambert wrote: > > It's because you have to reinstall, should you want to add a second > > OS at a later date (e.g. Linux, or Windows). > > I think it has more to do with the drive going on a new motherboard > that mi

Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-09 Thread Terry Lambert
Greg Lehey wrote: [ ... DTLA drives ... ] > > Do a Google/Tom's Hardware search to reassure yourself that I am not > > smoking anything. > > I think I'd rather put the shoe on the other foot. This looks like > high-grade crack. Who was smoking it? For your further amusement, here is a pointe

Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-09 Thread Terry Lambert
Greg Lehey wrote: > > [ ... IBM DTLA drives ... ] > > No, that wasn't me. I didn't quote the full thing; that's what the brackets and ellipsis was for. > > IBM DTLA drives are known to rotate fast enough near the spindle > > that the sustained write speed exceeds the ability of the controller

Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-09 Thread David W. Chapman Jr.
On Sun, Dec 09, 2001 at 06:46:24PM -0800, Terry Lambert wrote: > It's because you have to reinstall, should you want to add a second > OS at a later date (e.g. Linux, or Windows). I think it has more to do with the drive going on a new motherboard that might not boot with dangerously dedicated t

Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-09 Thread Greg Lehey
On Sunday, 9 December 2001 at 18:46:24 -0800, Terry Lambert wrote: > Greg Lehey wrote: > > [ ... IBM DTLA drives ... ] No, that wasn't me. > IBM DTLA drives are known to rotate fast enough near the spindle > that the sustained write speed exceeds the ability of the controller > electronics to k

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-09 Thread Terry Lambert
> 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 o

Re: "Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-09 Thread Terry Lambert
Greg Lehey wrote: [ ... IBM DTLA drives ... ] IBM DTLA drives are known to rotate fast enough near the spindle that the sustained write speed exceeds the ability of the controller electronics to keep up, and results in crap being written to disk. This is not often a problem with windows, the FS

Re: "Dangerously Decidated" yet again (was : cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-09 Thread Greg Lehey
On Sunday, 9 December 2001 at 18:32:38 -0800, Mike Smith wrote: >> On Sunday, 9 December 2001 at 19:46:06 +0100, Joerg Wunsch wrote: >>> >>> >>> Still, it's my opinion that these BIOSes are simply broken: > > Joerg's personal opinion can go take a hike. The reality of the > situation is that t

Re: "Dangerously Decidated" yet again (was : cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-09 Thread Mike Smith
> On Sunday, 9 December 2001 at 19:46:06 +0100, Joerg Wunsch wrote: > > > > > > Still, it's my opinion that these BIOSes are simply broken: Joerg's personal opinion can go take a hike. The reality of the situation is that this table is required, and we're going to put it there. End of story.

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-09 Thread Peter Wemm
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 s

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-09 Thread Matthew Dillon
: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

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-09 Thread Peter Wemm
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

"Dangerously Decidated" yet again (was : cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-09 Thread Greg Lehey
On Sunday, 9 December 2001 at 12:15:19 -0800, Mike Smith 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 boo

"Dangerously dedicated" yet again (was: cvs commit: src/sys/kern subr_diskmbr.c)

2001-12-09 Thread Greg Lehey
On Sunday, 9 December 2001 at 22:52:58 +1030, Daniel O'Connor wrote: > > 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-gathe

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-09 Thread Joerg Wunsch
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 fdis

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-09 Thread Mike Smith
> (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 DT

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-09 Thread Mike Smith
> 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

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-09 Thread Joerg Wunsch
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 co

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-09 Thread Joerg Wunsch
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 ma

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-09 Thread Daniel O'Connor
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 s

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-09 Thread sthaug
> 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

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-09 Thread Joerg Wunsch
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

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-08 Thread Bernd Walter
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

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-08 Thread Peter Wemm
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 sho

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-08 Thread Matthew Dillon
: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!

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-08 Thread Joerg Wunsch
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 pla

Re: cvs commit: src/sys/kern subr_diskmbr.c

2001-12-07 Thread Bernd Walter
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). > >