Current-Users archive

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

Re: >512bytes/sector support (Re: Support for 4KB sectors size disk ?)

On Tue, Jan 12, 2010 at 10:48:04PM +0900, Izumi Tsutsui wrote:
> 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.

No, the translation is all done with in the disk driver.
The fs code will request transfers in multiples of DEV_BSIZE (or 512).

The trawl is actually through the disk drivers to ensure they use the
physical sector size - not DEV_BSIZE and not a value that happens
to be in the lable.

Partitions and filesystem blocks/fragments will need to be suitable
aligned - since the disk driver will likely reject requests that are
not for a whole number of physical sectors - like they do now when
asked to read a number of bytes.


David Laight:

Home | Main Index | Thread Index | Old Index