Well, in order to separate this away from the device specific issues
regarding how to the disk device itself is indexed, you can run dumpfs
on the filesystem itself and look at the superblock.

NetBSD currently will only support filesystems where
  fs_fshift - fs_fsbtodb == 9

This affects, at a minimum, how the inode field di_blocks is counted.

For example, in the following dumpfs output:

  $ dumpfs ns33.sadfue.ufs | head 
  magic   11954   time    Sat Jul 25 04:20:35 1998
  cylgrp  static  inodes  4.2/4.3BSD
  nbfree  255442  ndir    2       nifree  344059  nffree  16
  ncg     168     ncyl    2682    size    2089277 blocks  2043562
  bsize   8192    shift   13      mask    0xffffe000
  fsize   1024    shift   10      mask    0xfffffc00
  frag    8       shift   3       fsbtodb 0
  cpg     16      bpg     1558    fpg     12464   ipg     2048
  minfree 10%     optim   time    maxcontig 1     maxbpg  256
  rotdelay 4ms    headswitch 0us  trackseek 0us   rps     60

the shift number on the line starting with "fsize" is 10 the number
after "fsbtodb" is 0".  Since 10-0 is 10, this filesystem expects 1024
(i.e. 2^10) byte sectors and will not currently work on NetBSD no
matter what media it is copied onto.

Now, the above filesystem was dd'd from a NeXT disk that I believe also
had 1024 byte device sectors, but that can theoretically be a separate
problem.  NetBSD also does not currently support disks with 1024 byte
device sectors.

Consider also the following dumpfs output is on an image of the
filesystem found on the NeXTstep 3.3 install CD:

  $ dumpfs ns33cd.ufs | head
  magic   11954   time    Sat Nov 12 00:44:21 1994
  cylgrp  static  inodes  4.2/4.3BSD
  nbfree  1406    ndir    3168    nifree  71290   nffree  51
  ncg     45      ncyl    89      size    182272  blocks  176323
  bsize   8192    shift   13      mask    0xffffe000
  fsize   2048    shift   11      mask    0xfffff800
  frag    4       shift   2       fsbtodb 0
  cpg     2       bpg     1024    fpg     4096    ipg     1984
  minfree 10%     optim   time    maxcontig 20000 maxbpg  512
  rotdelay 0ms    headswitch 0us  trackseek 0us   rps     5

Notice that the fs_fshift is 11 and fs_fsbtodb is 0, therefore
this filesystem expects 2048 (2^11) byte sectors.  This is
to be expected since as it originally came from CD media.  This
filesystem image will also not currently work on NetBSD.

As I said, I've had both of those filesystem images working
under NetBSD in the lab, but the current NetBSD sources will
not handle them, no matter on what media they are found.

Darrin

Brian Willoughby <brianw@sounds.wa.com> writes:
> Yeah.  The device has 512 byte blocks, and the filesystem has 1024 byte  
> "sectors."  As "der Mouse" pointed out, most NetBSD FFS filesystems are 1k/8k.