Subject: Re: kern/3460: block io unit for sd should be sector size
To: None <cgd@cs.cmu.edu>
From: Koji Imada - je4wob/2 <koji@math.human.nagoya-u.ac.jp>
List: netbsd-bugs
Date: 04/09/1997 17:21:52
>>>>> "Chris" == Chris G Demetriou <cgd@cs.cmu.edu> writes:

 Chris> Thinking about it, i don't think that should work.

 Chris> in that case, frag size would be 1k, nspf would be 1, but 1 * the
 Chris> disklabel sector size (512) != 1k.

 Chris> Unfortunately, i'm not sure how this is _supposed_ to work.  Looking
 Chris> at the comments in the FFS code, which say "assumes DEV_BSIZE byte
 Chris> sector size," doesn't help.

It's working on my NetBSD box. So It works. :-)

 >> disklabel sector size = 512
 >> partition boundaries, etc., in disklabel are in units of
 >> 512, since that's the disklabel sector size.
 >> FFS file systems image from 1k/sector disk(1k frag).
 >> FFS file systems built as usual.
 >> 
 >> is ok too(2 file systems exist in separate partition).

 Chris> Isn't this the same as the first example, above?  I'm still not sure

Yes.

 >> Using First method, disklabel sector size greater than or equal to
 >> physical sector size and file system sector size greater than or equal 
 >> to physical sector size is ok.

 Chris> This case is:

 Chris> disklabel sector size >= physical sector size

 Chris> file system sector size >= physical sector size

 Chris> disklabel sector size (not necessarily ==) file system sector size


 Chris> I'm not sure that this should work, especially for cases where file
 Chris> system sector size is less than the disklabel sector size, but it it

Sorry, one requirement is necessary. file system fragment must be
greater than or equal to disklabel sector size. Changing disklabel
sector size in this requirement to DEV_BSIZE is possible. But i didn't 
because more calculation needed,  

This makes possible to make ffs(with 512/1024 bytes fragment) on 256
( < DEV_BSIZE) bytes/sector media I have tested it(1.2MB floppy).

This is accomplished by block number translation from DEV_BSIZE unit
to physical sector unit in sdstart. In current sd.c implementation,
the block number of request(in struct buf) should be in DEV_BSIZE
unit. Then sdstart translates it in disklabel sector size unit and
calculate block number(not offset in partition). My patch in previous
mail adds translation of block number(and block count) in physical
sector size. Last translation makes 'disklabel sector size != physical 
sector size' possible.

 Chris> _can_ be made to work reliably I think this is the best (since this is
 Chris> a superset of the functionality of the other method).

maybe. But this needs some modification to file system(ffs, msdosfs)
code. So, i tried simple implementation(send-pr'ed one).

At first, i was not familiar with ffs implementation and underlying
block io. I just believed that ffs should work on non-512 bytes/sector
media. I think information in superblock seems to be
self-contained(disklabel information is not necessary) and block io's
are done in DEV_BSIZE unit(in sd.c). I attempted to change file system 
code and it worked(first method). In this case, file system(ffs) must
calculate file system sector size(from fragment size and nspf) and
information to change fragment to DEV_BSIZE unit (fsbtodb in
superblock is for fragment to file system sector size unit) when
mounted. This needs new field in superblock.

Later, i have understood that ffs code assumes block io's are done in
physical sector size unit. I deleted translation in sdstart and it
worked(second method). In this case, file system code doesn't need
modification and simple. But 'file system sector size == disklabel
sector size' is required.

 >> Which is preferable?

 Chris> Assuming it can be made to work reliably, the latter (what you're
 Chris> calling the "first method"), since it provides all the funcitionaly of
 Chris> the "second method," and more.

Yes, but adds complexity. I think balance of benefit and cost is
important. If 'file system sector size != disklabel sector size'
situation is not required, "second method" is recommended for it's
simplicity(but not interesting :-).
--
Koji Imada
koji@math.human.nagoya-u.ac.jp