Re: blocksizes

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

> >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