Re: DIRBLKSIZ differs between userland & kernel

[David Holland <dholland-tech%netbsd.org@localhost>]

On Mon, Feb 27, 2012 at 01:54:49PM +1030, Brett Lymn wrote:
 > > I don't think any of those is the right answer. Coda is not limited to
 > > running on top of ffs, so it shouldn't be doing only filesystem-
 > > independent things when talking to the filesystem it uses for storage.
 > > (Right?)
 > 
 > Right.
 > What the vfs layer for coda does for coda_readdir is wrap some goop
 > around doing a VOP_READDIR on the underlying filesystem.  In my case
 > since the containers lived on ufs that is what was used.

Sure. But then, as long as syntactically valid dirents come back it
shouldn't matter what DIRBLKSIZ is.

 > > Therefore it should be using the value from <dirent.h> in both the
 > > kernel and in venus. If it's running on top of ffs, ffs will provide
 > > dirents with padding at 512-byte intervals that it would think
 > > unnecessary, but I would think it shouldn't notice or care.
 > 
 > Well venus pads them to 1024 - there is a chance that venus won't fill
 > the entire block, if venus less than half fills the block then
 > ufs_readdir() gets garbage.

This I still don't understand. ufs_readdir doesn't read anything from
venus.

 > What I was
 > talking about in relation to this is that ufs_readdir() pulls the
 > directory block size from a "ufs-ified" version of the mount structure
 > attached as private data to the mount struct.  I had thought changing
 > that would fix the problem but as you rightly point out we are not just
 > dealing with ufs here so I could easily fix the problem for me but still
 > leave a lurking bug :(

Yeah, that's almost certainly not a good idea.

-- 
David A. Holland
dholland%netbsd.org@localhost