tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: blocksizes

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

Home | Main Index | Thread Index | Old Index