Re: blocksizes

[David Laight <david%l8s.co.uk@localhost>]

On Sun, Jan 24, 2010 at 12:21:52PM -0800, Matt Thomas wrote:
> 
> My feelings are this: when accessing the device through a bdevsw (d_psize or 
> d_strategy), will refer to daddr_t and will be units of the blocksize of the 
> device.  For block access (aka filesystem) only blocksize that are powers of 
> 2 will supported.
> 
> For raw device access, any native blocksize can be used (like 2352 for CD 
> audio).
> 
> The btodb/dbtob macros will need another argument to indicate where the block 
> size is obtained.
> 

That will just cause massive errors...
For disks I would go for transfer requests (eg from fs) that are either in
fixed units (BDEVSIZE, 512) or in bytes.

Much like the current block device transfers - where transfers must be a
multiple of 512 - transfers you need to be aligned to the physical
sector size.

Most filesystem code does it transfers in 'file system blocks' - so the
main restriction is aligning fs blocks onto disk blocks.

Forcing the raw disk block size through all the kernel layes will be
seriously buggy.

Care does need to be taken about which 'sector size' values are where.
Which may mean translating everything to use 64bit byte offsets.
At least that will reduce the number of times values are converted,
and ensure that convertions are, for the most part at least, done
using shifts, not division.

And I'm still of the believe that it should be possibly to 'dd' a
filesystem from media with one sector size to that with a different
sector size (provided the fs block size is larger than both).
This is already done when a CD image is copied to disk and then mounted.

        David

-- 
David Laight: david%l8s.co.uk@localhost