Re: File systems on 4k sector devices?

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

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

>> The 63 thing is an old MSDOS-related superstition and there's no
>> reason to follow it now. (Even if there ever was, which wasn't ever
>> entirely clear.)

>I suspect it comes from reserving the first track - whether for the
>boot code/bios or just to avoid crossing the track boundary is unclear.

There were many users of the first track which didn't really make clear
how many sectors they would occupy. This doesn't mean 63, but really
the size of the first track. 63 is just the virtual geometry used by
the BIOS for larger drives.


>Support for non-512 byte disks is somewhere between non-existant and patchy.
>Partially because it isn't actually obvious what to do!

The support for non-512 byte disks works fine.


>Constraints in the file system layout actually mean that some things
>that are currently treated as 'sector offsets' need to be 'byte offsets'.
>(Like the location of the disklabel on i386/amd64 etc)

Traditionally you use sector or block adresses, because that is the
only thing that you could use to access a disk without an inefficient
blocking/deblocking layer.

The NetBSD kernel however uses 'byte offsets' internally. Well, not exactly
byte offsets, but those scaled by 512 (aka DEV_BSIZE). This is different from
other BSD systems.

WAPBL is an exception, the position and size of the journal is stored
int terms of pyhsical disk sectors.

>My personal opinion is that a filesystem image should be copyable between
>physical media with different block sizes provided that the fs allocation
>unit remains larger than the physical sector size.

Should be possible, except for WAPBL.


>So with a 4k physical sector ffs would have to have a fragment size of
>at least 4k.

So it does.

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