da...@l8s.co.uk (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: mlel...@serpens.de "A potential Snark may lurk in every tree."