[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: DIRBLKSIZ differs between userland & kernel
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?)
> 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
> 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
Main Index |
Thread Index |