hmm, on Tue, Feb 13, 2007 at 08:18:50AM -0500, Kenneth R Westerback said that
> OpenBSD aligns to boundaries. It just makes up the boundaries, as do
> other OS's.  It's unfortunate that all OS's don't make up the same
> boundaries but until you can convince all OS developers to use the
> same fake geometry you'll have to live with the current situation.
> 
> OpenBSD makes absolutely no effort to get 'real' geometry
> information from USB attached disks. Too many such devices simply
> freak out and stop working when asked this difficult question.
> Others make up even more bizarre geometries than the one we use.
> 
> So OpenBSD uses 64*32, divides the number of sectors (which all
> devices do provide) by this value to give a cylinder count, and
> truncates the fractional cylinder. So up to 64*31 = 1984 sectors
> will be 'wasted'.

thanks for the src pointer, interesting.  this explains the dmesg
clearly, but what about fdisk?  fdisk is supposed to get the
geometry from the the bios (not much help for usb disks i guess)
and then the disklabel.  is disklabel using the same fake magic?


in the case of the 160G disk[1], there must be something wrong
as the dmesg total number of sectors is the same as the fdisk
total number of sectors, while it's pretty clear that not all
of the disk is usable and there is a 5103 sectors of waste...


i believe you when you say a lot of umass stuff is broken
and choking on basic calls.  but wouldn't it make sense
to tell sd_get_parms() to go ahead and query an actual
geometry in case of "external hdd" usb devices?  are the
usb disks just as broken as any random umass device in this
respect?


i don't have a netbsd install to test it, but their approach
seems te be not as discriminative towards umass devices[2]...



btw this disk (wd passport) is strange in more respects.
first of all, partition magic got its geometry wrong also
a couple of times:

310,101 Cylinders,  16 Heads, 63 Sectors/Track   but then
 19,457 Cylinders, 255 Heads, 63 Sectors/Track[2].


second:

14:48:07 a /bsd: sd0(umass0:1:0): Check Condition (error 0x70) on opcode 0x2a
14:48:07 a /bsd:     SENSE KEY: Illegal Request
14:48:07 a /bsd:      ASC/ASCQ: Logical Block Address Out of Range
14:50:21 a /bsd: sd0(umass0:1:0): Check Condition (error 0x70) on opcode 0x2a
14:50:21 a /bsd:     SENSE KEY: Illegal Request
14:50:21 a /bsd:      ASC/ASCQ: Logical Block Address Out of Range
14:50:56 a /bsd: sd0(umass0:1:0): Check Condition (error 0x70) on opcode 0x2a
14:50:56 a /bsd:     SENSE KEY: Illegal Request
14:50:56 a /bsd:      ASC/ASCQ: Logical Block Address Out of Range
14:53:53 a /bsd: sd0(umass0:1:0): Check Condition (error 0x70) on opcode 0x2a
14:53:53 a /bsd:     SENSE KEY: Illegal Request
14:53:53 a /bsd:      ASC/ASCQ: Logical Block Address Out of Range

so this baby is certainly going back where it came from...


-f

1. http://marc.theaimsgroup.com/?l=openbsd-misc&m=117133082530013
2. http://opengrok.netbsd.org/source/xref/sys/dev/scsipi/sd.c#sd_get_parms
3. http://marc.theaimsgroup.com/?l=openbsd-misc&m=116475065104125&w=4
-- 
the word of the day is legs.  now spread the word!

Reply via email to