Re: blocksizes

[mlelstv%serpens.de@localhost (Michael van Elst)]

david%l8s.co.uk@localhost (David Laight) writes:

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

To be true, that's how it was 'in the beginning' of Unix and
a rough check shows that FreeBSD still does it that way.


Touching lots of code to go back to this model is what I fear.


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

I don't see that it would reduce the number of conversions.

Filesystem blocks -> some intermediate value -> disk blocks.

Wether the intermediate value is bytes or DEV_BSIZE units
doesn't matter (and a single division doesn't matter anyway
if you think about performance).

Not having some intermediate value on the other hand avoids
an operation but shifts the complexity into the upper layer.

The upper layer of course already deals with this to some
degree due to its heritage.


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

FFS isn't meant to work this way. The translation from
filesystem block to (physical!) disk block is encoded
into the superblock. That's why FFS currently fails
on non-512bytes-sectors, newfs uses the translation
to physical sectors, the kernel needs the translation
to DEV_BSIZE.

Currently I just tell newfs to write the information
that the kernel needs. Of course that is incompatible
with say a FreeBSD FFS image and telling the kernel to
compensate internally is probably the correct way.

-- 
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."