tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Support for 4KB sectors size disk ?



(Sorry, re-post with correct address)

abs%NetBSD.org@localhost wrote on current-users:

> (Irrelevant historical sidetrack)
> 
> I thought at one point it was common for BSD derived systems to be
> able to support arbitrary block sizes? Certainly I remember using
> 42nix (BSD 4.2+clutter on NS32016) and being able to format the MFM
> drives with differing block sizes.
> 
> So technically this may be a facility that has just atrophied from lack of 
> use.

FYI, here is my dumb thought suggested to post tech-kern@
in private discussion.

--- original message ---

As mentioned in PR 3790-3792, we need not only "implementation fix"
but also "design decision" for !512bytes/sector device support:

 * physio(9)/bread(9)/bwrite(9)/getblk(9) etc. should be able to
   handle I/O in unit less than hardware sector size or not
 * size of unit for "blkno" should be constant (traditional 512bytes)
   or variable per device (hardware sector size).

I guess we have had a bunch of PRs with random fixes due to
lack of the decision.


In traditional implementation, DEV_BSIZE means minimum I/O size of
hardware devices, and it's always same as hardware sector size.
        
To support >512bytes/sector devices, we may have two choice:
 (1) make DEV_BSIZE (I/O size) variable (per hardware sector size)
 (2) keep DEV_BSIZE (I/O size) constant (traditional 512bytes)

For the former, we need less fixes in file system code
(just nuke DEV_BSIZE constant and replece it with "sector size"
 value stored somewhere), but we have to rewrite all physio(9)
and friend functions to take actual sector size for I/O unit.

For the latter, we don't have to fix I/O functions, but
we have to add conversions from sector (disk block) size to
DEV_BSIZE in all file system code (and more other places).
For example, currently number of disk blocks calculated by
fsbtodb() is directly passed to bread(9) and getblk(9) in ffs.

I'm afraid the latter could cause performance penalties
on unaligned block access, but there are too many code
with assumption that unit of I/O size is constant.
(i.e. no generic way to get actual I/O (== sector) size)

We have to consider about tradeoff, but I'm afraid
it's too dificult to choose one of them.
---
Izumi Tsutsui


Home | Main Index | Thread Index | Old Index