> >The design of FFS is independent from design of our buffercache(9) > >or all disk drivers, so if FFS has its own "disk block size" value > >in its superblock, we have to check and convert (or reject) > >the "FFS disk block size value" for our native I/O size > >whichever we will choose DEV_BSIZE or physical block size. > >(fragment size -> FFS disk block size -> our I/O size) > > Ignoring the fsbtodb translation from the superblock is probably > the way to go.
To translate file system block size (i.e. unit of fragment size) into raw I/O size, we can ignore fsbtodb. But inode entries in ffs (di_blocks in strcut ufs1_dinode) use the "FFS disk block size" to count blocks so we have to translate it anyway. We also have to think how we can determine DIRBLKSIZ for atomic ops. > >Note lfs and ext2fs have the same issue. > > lfs is obvious (same code as ufs). I haven't looked at ext2fs. ext2fs itself doesn't have fsbtodb member in superblock. But our implementation prepare it in struct m_ext2fs to share structures among other ufs code, and ext2fs_vfsops.c says "XXX assume hw bsize = 512". Oh well. --- Izumi Tsutsui
