> >Disklabel in cd(4) requires hardware block size for partition offsets, > > All disklabels use hardware block sizes. cd(4) is no exception. > > >but it also uses DEV_BSIZE for sizes. > > cd(4) uses DEV_BSIZE units to address blocks.
I meant size parameters in struct disklabel, like d_secperunit and d_partitions[].p_size etc. On sgimips installcd, disklabel(8) says: --- 16 partitions: # size offset fstype [fsize bsize cpg/sgs] a: 333824 1024 4.2BSD 1024 8192 16 # (Cyl. 0*- 163*) c: 337920 0 unknown # (Cyl. 0 - 164) i: 4096 0 unknown # (Cyl. 0 - 1) --- The offset of partition a should be same as size of partition i? > >Isn't it one example of inconsistent hacks? > > No, this is a place where this is used consistently. Maybe > it becomes clear when treating the disk address not like > a way to access hardware but a way to specify the data > layout. > While these are related, it is not a 1:1 relationship. Consistent per what? I don't think current implementation was written per consistent design. It might look consistent, but there are many possible botches so we have to check all use of DEV_BSIZE (and lp->d_secsize, fsbtodb etc.) whether they should be hardware blocksize or logical one. All ufs code uses d_secsize to read superblock, for example. > >There is no "right" solution. We can fix the hack with hacks, > >or we can also redesign it. Someone[tm] should make a decision. > >That's all. > > Yesterdays' redesign is todays' hacks. By chosing words you > already say what you consider a "wrong" solution. > > So far I have heard about three models. > > - use DEV_BSIZE addressing (that's what we have now, no changes) s/no changes/less diffs/ In this case, we still have to use physical block size in some more drivers, and we always have to consider which logical or physical one should be used. > - use byte addressing (almost the same, just a few bits more, requires > minor changes to device drivers and other code). > - use native block addressing (what we left in 1994, requires significant > changes to device drivers and minor changes to other code). In the last case, we could have a common API to get physical block size for optimized min xfer size as side effect? > To me, none of this has significant advantages. (BTW, did you take a look at PRs 3790-3792?) I still think there is some tradeoff among them (less diffs, or no logical vs physical confusion). Probably we should ask Core. FYI, here is a current result of 2KB/sector MO disk: --- # dmesg | grep sd0 sd0 at scsibus0 target 0 lun 0: <KONICA, OMD-7062, 1.12> optical removable sd0: fabricating a geometry sd0: 606 MB, 151 cyl, 64 head, 32 sec, 2048 bytes/sect x 310352 sectors sd0: fabricating a geometry sd0: sync (100.00ns offset 15), 8-bit (10.000MB/s) transfers # disklabel sd0 # /dev/rsd0d: type: SCSI disk: OMD-7062 label: fictitious flags: removable bytes/sector: 2048 sectors/track: 32 tracks/cylinder: 64 sectors/cylinder: 2048 cylinders: 151 total sectors: 310352 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # microseconds track-to-track seek: 0 # microseconds drivedata: 0 4 partitions: # size offset fstype [fsize bsize cpg/sgs] a: 310352 0 4.2BSD 0 0 0 # (Cyl. 0 - 151*) d: 310352 0 unused 0 0 # (Cyl. 0 - 151*) disklabel: boot block size 0 disklabel: super block size 0 # newfs /dev/rsd0a /dev/rsd0a: 606.2MB (310352 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 151.55MB, 9699 blks, 19072 inodes. rdfs: read error for sector 3: Invalid argument # newfs -S 2048 /dev/rsd0a /dev/rsd0a: 606.2MB (310352 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 151.55MB, 9699 blks, 19072 inodes. rdfs: read error for sector 3: Invalid argument # gpt create sd0 # gpt add sd0 Partition added, use: dkctl rsd0d addwedge dk<N> 10 310333 <type> to create a wedge for it # dkctl /dev/rsd0d addwedge dk0 10 310333 ufs # gpt show sd0 start size index contents 0 1 PMBR 1 1 Pri GPT header 2 8 Pri GPT table 10 310333 1 GPT part - NetBSD UFS/UFS2 310343 8 Sec GPT table 310351 1 Sec GPT header # newfs /dev/rdk0 newfs: /dev/rdk0 partition type is not `4.2BSD' # newfs -I /dev/rdk0 /dev/rdk0: 606.1MB (310333 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 151.53MB, 9698 blks, 19072 inodes. wtfs: write error for sector 310332: Invalid argument # newfs -S 2048 -I /dev/rdk0 /dev/rdk0: 606.1MB (310333 sectors) block size 16384, fragment size 2048 using 4 cylinder groups of 151.53MB, 9698 blks, 19072 inodes. wtfs: write error for sector 310332: Invalid argument # --- Izumi Tsutsui