| On 4 Jun 2002 eeh@netbsd.org wrote:
|
| > | currently every disk driver and almost all of the rest of the system
| > | assume b_blkno is in units of DEV_BSIZE, so it would definitely be easier
| > | to fix the few places that assume something else than to switch everything
| > | that assumes units of DEV_BSIZE.
| > |
| > | as for FFS, I think the only place it has a problem is in its usage of
| > | the fs_fsbtodb field in the superblock.  code that uses this field is
| > | attempting to convert from a fragment size to the units of b_blkno,
| > | so such code should really just compute the desired value
| > | 	(fs->fs_fshift - DEV_BSHIFT)
| > | rather than using the value in the superblock.
| >
| > Where do you do the read-modify-write operations needed to write data in
| > increments smaller then the device block size?  And how do you make sure
| > you don't get corruption when there are two operations that want to write
| > to different DEV_BSIZE parts of a single device block?  Don't forget that
| > things like fsck need to be able to do those sorts of operations without
| > the benefit of the buffer cache.
|
| As I understand what Chuck did, all i/os have to be in terms of underlying
| disk sectors. So you won't get two writes to sub-sector parts because you
| can't write less than a sector.

Actually, I thought it was the other way around.  All IOPs are done in terms
of DEV_BSIZE.  If they were all done in terms of the device's block size we
wouldn't be having any of this conversation and 2KB devices would just work.

I suppose I need to re-read large parts of the kernel post-UBC to see what's
really going on now.

Eduado