Current FFS on NetBSD can work only with 512 bytes/secotr media. More
exactly, with DEV_BSIZE bytes/sector media.

I think it's not limitation of FFS but NetBSD limitation. So I have
examined source codes and tested some modification.

Is there anyone working with this problem? following is my result.

Current limitation is DEV_BSIZE dependent one. Unit of block io in
kernel is DEV_BSIZE. This is acceptable implementation limitation. But 
FFS should handle other than DEV_BSIZE sector size media.

This limitation comes from two causes.

1. ffs implementation.
2. device driver implementation.

For 1. in ffs code, internal unit of block io is fragment size. It is
converted to DEV_BSIZE unit using macro fsbtodb and dbtofsb when doing 
block io. Macros fsbtodb and dbtofsb just shift fs_fsbtodb bits in
struct fs.

For 2. Some driver doesn't set correct device parameters and disklabel
and partition routine uses DEV_BSIZE but physical sector size.

So two method will be available to handle not DEV_BSIZE(512)
bytes/sector media.

one method is using DEV_BSIZE based parameters in superblock,
disklabel and etc(pr bin/2404). And another is modifying DEV_BSIZE
dependent part to use sector size.

My modification is later one and tested on SCSI 640MB MO(2048
bytes/sector) and floppy(1024 bytes/sector and 256bytes/sector).

To use ffs on 2048 bytes/sector. Following problem happens.

Problem 1.
	What does fs_fsbtodb in struct fs(super block) means? I think
	this means differential of fragment size and disk block size.
	Now, ffs can handle only 512bytes/sector media. So it is
	equivalent to differential of fragment size and
	DEV_BSIZE(block io unit). But it's not same if sector size is
	not DEV_BSIZE.

	fs_fsbtodb in superblock should mean differential of fragment
	size and disk block size(sector size). Or file system can't be
	available if DEV_BSIZE in machine/param.h is changed. This is
	not acceptable.

	In the other hand, fs_fsbtodb means differential of fragment
	size and disk block size(sector size). DEV_BSIZE can be
	changed if necessary(ex. to use 256 bytes/sector device using
	256bytes fragment size).

	To resolv this problem, macros fsbtodb and dbtofsb should use
	some value computed from fs_fsbtodb and DEV_BSIZE rather than
	fs_fsbtodb in superblock. I want new field in superblock which
	may be changed when mounted. And macros should be changed.

	In my current modification, changing fs_fsbtodb when reading
	and writing superblock. This is quick hack. And macro fsbtodb
	and dbtofsb check sector size is smaller than DEV_BSIZE or
	not.

Problem 2.
	How does information in disklabel stored? I prefer physical
	sector size based information(offset, size and etc).

	Current bounds_check_with_label in
	sys/arch/<arch>/<arch>/disksubr.c use DEV_BSIZE to check
	bound. I have modified to use d_secsize in struct disklabel.

	This modification is tested on NetBSD/i386, but easily applied 
	to other architecture.

Problem 3.
	Some device driver can handle only DEV_BSIZE media. sd.c of
	1.2R can't detect sector size of optical disk. But SCSI
	command read capacity returns block count and block size of
	device. It can be used.

Problem 4.
	msdosfs needs modification like ffs. This is send-pr'ed by
	Mr. Minoura(port-i386/2895, port-sparc/2903).

Now I can use ffs on 640MB MO. It's faster than msdosfs. I'm happy.

How about this? I will send diffs for NetBSD/i386 if superblock
problem(problem 1) is decided.
--
Koji Imada - je4owb/2
koji@math.human.nagoya-u.ac.jp