Subject: Re: Supporting sector size != DEV_BSIZE
To: None <tech-kern@netbsd.org>
From: Trevin Beattie <trevin@xmission.com>
List: tech-kern
Date: 06/10/2002 16:13:09
At 02:21 PM 6/10/2002 -0700, Konrad Schroder wrote:
>On Mon, 10 Jun 2002, Trevin Beattie wrote:
>
>> As I've said before, I don't want to do anything that will break existing
>> file systems, if I can avoid it. OTOH, since the existing kernel is broken
>> WRT sector size != DEV_BSIZE, I think it's safe to base any changes on the
>> premise that DEV_BSIZE == sector size on all working file systems.
>
>I don't; not because our current kernel works for DEV_BSIZE!=512, which
>maybe it doesn't, but because it definitely did work for someone once.
>(Maybe they didn't run the current NetBSD, or even NetBSD at all, that's
>not the point.)
>
>If we had a mechanism for addressing filesystems that had been built with
>DEV_BSIZE=1024, we could mount old filesystems for systems that were built
>that way, and worked just fine when they were built; the NeXT comes to
>mind as a system that shipped with 1kB sectors. Our FFS will currently
>mount 4.2-FFSes (read-only?) and dtrt; if we change the filesystem(s)
>to understand different sector sizes than 512, we should be able to get
>these historical 1k-sector fss "for free".
I never knew that about NeXT; my 'Cube has been running with standard
512B/s hard drives and a 2048B/s Fujitsu optical drive. I've had it boxed
up and put in storage though for the past two years, so I won't be able to
do much testing on it soon.
That brings us back to the question: what values do these systems store in
the fs structures? And how can that be resolved with our goal to define
the structure contents so that it works with all sector sizes? What if we
find two examples of valid file systems created by different OS's which use
the same file system type but different scales for some of the variables
(like fs_nspf)? Then there would be no way we can define a single model
that will work for both of them.
It would really be great if, in addition to reviewing my patches, some
people could actually try them out on existing file systems of different
block sizes and provide feedback as to whether the changes make things
work, break something, or have no effect.
-----------------------
Trevin Beattie "Do not meddle in the affairs of wizards,
trevin@xmission.com for you are crunchy and good with ketchup."
{:-> --unknown