Re: DIRBLKSIZ differs between userland & kernel

[Brett Lymn <brett.lymn%baesystems.com@localhost>]

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