Date: Mon, 1 May 1995 11:27:33 -0700 (PDT) From: pete@pelican.com (Pete Carah) To: bde@zeta.org.au (Bruce Evans) Cc: current@FreeBSD.org Subject: Re: fdisk+disklabel, etc Message-ID: <m0s60Bx-000K0iC@pelican.com> In-Reply-To: <199505010724.RAA20670@godzilla.zeta.org.au> from "Bruce Evans" at May 1, 95 05:24:50 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans writes: > No, fdisk defaults to the numbers in the label, which currently gives > numbers guessed from the partition table. I'm running current from Friday or Saturday... That wasn't what mine did; I could *never* get a label written at all, once fdisk had been done with *any* reasonable parms. It always refused to write it out (with -w -r). Part of the problem may be that this is a 540mb drive so the 1023 hack won't work. I once had a dos scsi driver (in 1983!) that ignored the slice table chs values completely and went only by the 32-bit numbers. Why else are they in there!! I admit that dos's format and fdisk won't work with that since they insist on using int 13 for everything... We don't except for initial boot; why pay *any* attention to them? > Do you have a current sbin/disklabel? Old versions silently truncate > d_secperunit to a cylinder boundary if you write out the label using > `disklabel -e'. This causes problems if the size of the C partition > isn't truncated to match. Yes. (if last Saturday is current enough). > >to yell "stop"). The slice size should probably match the 'identify' > >size at least for scsi disks. > Disk size? Fdisk needs to allow larger sizes, at least for non-scsi > disks. I've just remembered that I have some ST506 disks with >1024 > cylinders in storage. My BIOSes couldn't handle this, but the disks > could be used by telling fdisk the actual number of cylinders. When > the geometry-guessing stuff in the drivers goes away (we're going to > rely on the geometry reported by the drive or the BIOS geometry), then > drivers will still have to set the number of cylinders to > max(BIOS number, max in partition table). That is part of what I wanted to hear; please do ignore the chs stuff in the slice table at least for sd drives. Remember that dos doesn't use them for this purpose either; there is a geometry description pointed to in int 41 and some other that is used. No guessing involved, and once fdisk'd, dos does NOT insist on things being on cyl boundaries; it is only a convenience for fdisk. It may involve the boot getting bigger to get these without clobbering anything at boot time. > >These disks also report sec/trk numbers > >that are too high. The drive I've got here has a size that doesn't > Too low. They are calculated by the driver, rounding down. Well 92 > 64... That's what I meant by too high. The reality is that the sec/trk number is not constant for most of these drives, so *anything* you do with it is bogus, unless you get the breakpoint table from the drive and use it to figure out true cylinders. In any case this won't fit in a slice table. > There's not going to be a suitable factorization in general. I suggest > using "Adaptec" geometry (64H 32S) for drives up to 1GB and keep doubling > the number of heads for larger drives if you want to keep the number of > cylinders <= 1024. Unfortunately, this stops working after 4G (256H) > and you have to use a non-power of 2 for the number of sectors. Also, > my (Buslogic) scsi BIOS seems to always use 64H 32S although it claims > to support drives with > 1024C, so it only supports 1/4 of one of my > drives under DOS. I don't really mind since I don't need to use the > drive for DOS. That is one (of many) thing I tried. *nothing* let me write a label using the correct description in disktab, either with some fdisk or with the slice-table area zeroed. Your trick of faking out the label then editing to the *same* parms worked. Something is very funny in disklabel... (and disklabel needs to ignore geometry too for the initial write and rely on the origin/size variables only, just like the driver needs to.) > >Also, giving the "no magic" message is bogus on a write to rsd1... > >(dd'ing /dev/zero to it, for example). A raw disk device can be used > >for anything, for example SGI uses raw unlabelled disks for video to > > My floppy driver supports slices so I get it for floppies too. It is > very annoying for floppies but I think it should stay for hard disks. > I don't like all slices and partitions depending on 2 magic bytes. NO NO NO. As I said, there are other uses that disks can have. There should be *no* messages normally in circumstances expected for a given device; since the raw whole-drive device can be used for anything, the message is truly bogus. *(minor) flame on* Personally I don't like *any* of the per-open driver messages; I hope a #define can be put in to suppress them except in cases of *true* errors or inconsistencies (or boot -v or such). Also the current slice code detects inconsistencies (by believing the geometry from the slice table) that aren't there for sd.. devices. We don't need the geometry at all, especially since newfs ignores it now anyway. It truly has no use except to confuse users of fdisk. Maybe the first time a given set of values is loaded would be OK if you insist, but *never* thereafter. Such messages belong only as a debugging tool (boot -v or such?). > >avoid the fs overhead; a kernel message (even a syslog) would kill a > >vertical-interval time... > > So would unnecessary open()s :-). Yes, but that is faster than a non-interruptable message of a line or so. remember that this message holds EVERYTHING running, not just the proc that did the open. Admittedly no extra opens get done there either. -- Pete
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0s60Bx-000K0iC>