Re: blocksizes

[Michael van Elst <mlelstv%serpens.de@localhost>]

On Mon, Feb 01, 2010 at 09:10:05PM +0000, David Laight wrote:
> On Mon, Feb 01, 2010 at 08:58:31PM +0000, Michael van Elst wrote:
> > 
> > The superblock already stores block sizes in terms of byte counts.
> > 
> > The problem is that it stores information that shouldn't be there but
> > which depends only on the underlying medium. If you change the medium
> > you invalidate that information.
> 
> Do you ?

fs_fsbtodb depends on the block size of the underlying medium. Changing
the block size makes fs_fsbtodb invalid.


> Or do you just require that, for some actions, the fs code treats the
> numbers in the superblock as refering to the original block size - and
> if the current block size is different, acts to maintain the existing
> filesystem layout.

the original block size has no meaning. My guess is that the
information was stored in the superblock because it couldn't
be retrieved otherwise. From a software engineering point of
view it also makes sense to keep the filesystem parameters
in some internal data structure but since that got dumped to
the disk, we have to live with the current situation.


> There is also the case that non-512 byte ffs are extremely rare, and that
> modern netbsd ffs are not really compatible with other systems any more.

You can still mount a FreeBSD filesystem or... an Apple UFS filesystem.


> So precisely what the exact definitions of some of these fields are
> can be bent slightly.

Changing fs_fsbtodb breaks lots of things that still think in terms
of device block sizes and use fs_fsbtodb to deduce that size. And
that's almost everything but the NetBSD kernel.

It's much easier to ignore fs_fsbtodb completely. If you want to
change userland to do the same, you can do that. But as long as
we keep fs_fsbtodb compatible, there is no need. Also, changing
the definition of fs_fsbtodb just breaks old userland binaries.


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