On Mon, 10 Jun 2002, 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.)

I'm sorry, that didn't parse. What worked for someone once?

From the systems I've worked with in the past (old BSD iron), systems that
wanted say 1k or 2k disks ran the whole OS with that-size disks. i.e.
DEV_BSIZE == 1k or 2k. So what's wrong with taking DEV_BSIZE=sector size
as a ref?

> 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".

The other problem with NeXT file systems (which we face with MacOS X UFS
file systems) is that the directory entry size is bigger. :-(

Take care,

Bill