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 [email protected]
