On Fri, Apr 19, 2013 at 01:48:21AM +0200, Swa Frantzen wrote:
> Hi,
>
> Probably more of a feature request than a bug - but there's little info out
> there on how to work around it (or I failed to find it).
>
> System: OpenBSD 5.2 amd64
> Pretty much stock.
>
> DIsk: Seagate Backup+ Desktop 4Tbyte
>
> dmesg says this when plugging it in (USB):
> --->8---
> umass0 at uhub4 port 1 configuration 1 interface 0 "Seagate Backup+ Desk" rev
> 2.10/1.00 addr 6
> umass0: using SCSI over Bulk-Only
> scsibus3 at umass0: 2 targets, initiator 0
> sd0 at scsibus3 targ 1 lun 0: <Seagate, Backup+ Desk, 0503> SCSI4 0/direct
> fixed
> sd0: 3815447MB, 4096 bytes/sector, 976754645 sectors
> --->8---
>
> Init it with fdisk, disklabel to make an "a" partition spanning the available
> space:
> # fdisk -i sd0
> Do you wish to write new MBR and partition table? [n] y
> Writing MBR at offset 0.
> # fdisk sd0
> Disk: sd0 geometry: 60800/255/63 [976754645 4096-byte Sectors]
> Offset: 0 Signature: 0xAA55
> Starting Ending LBA Info:
> #: id C H S - C H S [ start: size ]
> -------------------------------------------------------------------------------
> 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
>
> 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
>
> 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
>
> *3: A6 0 1 2 - 60799 254 63 [ 64: 976751936 ] OpenBSD
> # disklabel sd0
> # /dev/rsd0c:
> type: SCSI
> disk: SCSI disk
> label: Backup+ Desk
> duid: 0000000000000000
> flags:
> bytes/sector: 4096
> sectors/track: 63
> tracks/cylinder: 255
> sectors/cylinder: 16065
> cylinders: 60800
> total sectors: 976754645
> boundstart: 64
> boundend: 976752000
> drivedata: 0
>
> 16 partitions:
> # size offset fstype [fsize bsize cpg]
> c: 976754645 0 unused
> kvasir# a
> bash: a: command not found
> kvasir# disklabel -E sd0
> Label editor (enter '?' for help at any prompt)
> > p
> OpenBSD area: 64-976752000; size: 976751936; free: 976751936
> # size offset fstype [fsize bsize cpg]
> c: 976754645 0 unused
> > a
> partition: [a] a
> offset: [64]
> size: [976751936]
> FS type: [4.2BSD]
> > p
> OpenBSD area: 64-976752000; size: 976751936; free: 0
> # size offset fstype [fsize bsize cpg]
> a: 976751936 64 4.2BSD 16384 131072 1
> c: 976754645 0 unused
> > w
>
>
> # disklabel -v sd0
> # /dev/rsd0c:
> type: SCSI
> disk: SCSI disk
> label: Backup+ Desk
> duid: 99f3f6850096e833
> flags:
> bytes/sector: 4096
> sectors/track: 63
> tracks/cylinder: 255
> sectors/cylinder: 16065
> cylinders: 60800
> total sectors: 976754645
> boundstart: 64
> boundend: 976752000
> drivedata: 0
>
> 16 partitions:
> # size offset fstype [fsize bsize cpg]
> a: 976751936 64 4.2BSD 16384 131072 1
> c: 976754645 0 unused
>
> asd then newfs ?
> All straightforward on other disks, but here so such thing ...
>
> newfs gives:
> # newfs /dev/rsd0a
> newfs: block size 131072 is too large, maximum is 65536
>
>
> Now disklabel has an expert mode where you can reduce the block size, but
> documentation I've seen so far is sparse. And impact of it is unclear for now
> (I'm still testing the disk).
>
> What do I suggest:
> - make sure that disklabel selects parameters on its own where newfs is happy
> with, or at least give a warning that it's not going to work out.
> - enhance disklabel's man page to point to explanations and/or explain the
> bsize and fsize parameters a little bit. I know, understand and agree with
> the obvious drawbacks to documenting things that should not be changed ? but
> if we're going to have issues with what's chosen automatically, we should
> have documentation about what the impact of the change is in order to not
> make it worse.
>
>
> My workaround so far (mostly untested):
> # disklabel -E sd0
> Label editor (enter '?' for help at any prompt)
> > X
> Entering expert mode
> > p
> OpenBSD area: 64-976752000; size: 976751936; free: 0
> # size offset fstype [fsize bsize cpg]
> a: 976751936 64 4.2BSD 16384 131072 1
> c: 976754645 0 unused
> > d
> partition to delete: [] a
> > a
> partition: [a]
> offset: [64]
> size: [976751936]
> FS type: [4.2BSD]
> fragment size: [16384]
> block size: [131072] 65536
> Align partition to block size: [y]
> > p
> OpenBSD area: 64-976752000; size: 976751936; free: 0
> # size offset fstype [fsize bsize cpg]
> a: 976751936 64 4.2BSD 8192 65536 1
> c: 976754645 0 unused
> > w
> > q
> No label changes.
> kvasir# newfs sd0a
> /dev/rsd0a: 3815437.2MB in 7814015488 sectors of 4096 bytes
> 1168 cylinder groups of 3266.88MB, 52270 blocks, 104704 inodes each
> super-block backups (for fsck -b #) at:
> 256, 6690816, 13381376, 20071936, 26762496, 33453056, 40143616, 46834176,
> 53524736, 60215296, 66905856, 73596416, 80286976, 86977536, 93668096,
> [rest suppressed for brevity]
>
> newfs's -b option is probably another way around the problem (I didn't try
> it), but that has a drawbacks too (e.g. remembering redoing changing the
> default block size when quickly wiping the disk)
>
> --
> Swa Frantzen
This is a bug. The blocksize disklabel computes should be max 2^16.
fsck -b is indeed a workaround. It records the fragment and blocksize
used in the disklabel, so subsequent newfs calls (withiut -b or -f)
will use the same parameters.
-Otto
