Subject: Re: DEV_B_SIZE
To: None <phk@freebsd.org>
From: Terry Lambert <tlambert2@mindspring.com>
List: tech-kern
Date: 01/31/2003 17:19:59
phk@freebsd.org wrote:
> In message <Pine.BSF.4.21.0301311144370.45015-100000@InterJet.elischer.org>, Ju
> lian Elischer writes:
> >One thign I thought of is that it is not uncommon to 'dd' an entire
> >filesystem from one partition to another.
> >If we create a filesystem that is 'aligned' and we copy it to be
> >'unalligned', we'd have a sudden performance drop for no immediatly
> >obvious reason. What was one write, would become a 2-sector read,
> >modify and 2-sector write. Especially when copying from one failing
> >drive to another with slightly different characteristics.
>
> If you run dd without bs=ALOT you deserve bad throughput.
I think he means that the performance of the resulting FS, if
it had expectations of running on a 4K block size, and got a
512b one instead, would be unexpected (e.g. the only difference
between the disks is a "Q" or "R" at the end of the disk model
number, etc.).
The real answer, if that's what you mean, Julian, is that the
FS is not likely to be transportable between the devices, or,
minimally, from a 512b to a 4K, because of the existing data
not having taken the 4K alignment issues into account (e.g.
directories would be an even multiple of 512b in length, rather
than an even multiple of 4K in length). From a 4K to a 512b,
there's might also be an offset issue, if they were not treated
internally as if they were 512b on 4K systems, for data storage,
and only treated as 4K for atomicity.
My recommendation would be to indicate doing this is no longer
supported between drives of different physical block sizes.
FWIW, the original NEC PC98 disks were 1K physical block size
disks. It might be worthwhile to ask the PC98 folks about
problems, but I'm going to guess that none of their fictitious
geometries, before they moved to using standard disks, was
ever an odd sector count per track.
-- Terry