On Mon, Feb 27, 2012 at 07:50:51AM +0000, David Holland wrote: > > > > 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. >
Well, syntactically correct they may be but if a dirent straddles the DIRBLKSIZE boundary then things will break. I think this is what happens. Venus carefully aligns dirents to the 1024 byte boundary but ufs_readdir() rounds down to the nearest 512 byte boundary when it is doing its processing - if that happens to be part way through a dirent that venus has provided then the nasal demons happen. At the moment I am wondering if I shouldn't just do a statvfs() on the filesystem and use the device block size instead of DIRBLKSIZE. > > > > 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. > Actually it does. The way that coda works currently is a bit complicated, it does part of its work in the kernel but part of it is passed up to venus. A lot of the file system semantics are handled within venus, the fs data is actually stored in a container file and venus is the one that handles getting data into the container from the server (if it is not already cached in there), pushing data from the container back to the server (when there is a connection), satisfying reads/writes from the local system and a lot of other things. When you do a getdents(2) call on a coda directory the readdir syscall eventually gets called. This is directed to coda_readdir() by VOP_READDIR, coda_readdir() checks if the container file is open already and opens it if it is not. Once the container file is open then coda_readdir() calls VOP_READDIR on the underlying fs, in my case this gets directed to ufs_readdir(). Inside ufs_readdir() a VOP_READ is performed to get the directory data. In this case this is handled by coda_read() which forms up a request does an upcall to userland for venus to handle the request. Venus looks at the request and sees that it is a request for a read of a directory so it takes the coda directory entries and on the fly forms up a series of dirents to satisfy the read request and hands this back to the kernel. Then ufs_readdir() processes this data. -- Brett Lymn "Warning: The information contained in this email and any attached files is confidential to BAE Systems Australia. If you are not the intended recipient, any use, disclosure or copying of this email or any attachments is expressly prohibited. If you have received this email in error, please notify us immediately. VIRUS: Every care has been taken to ensure this email and its attachments are virus free, however, any loss or damage incurred in using this email is not the sender's responsibility. It is your responsibility to ensure virus checks are completed before installing any data sent in this email to your computer."
