Re: DIRBLKSIZ differs between userland & kernel

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

On Mon, Feb 27, 2012 at 02:43:51AM +0000, David Holland 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.

> 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.
 
> Then again, maybe I don't understand what's going on, as there
> shouldn't be any way for ufs_readdir to see, much less trip on,
> dirents generated by venus.

As above, the coda_readdir() in coda_vnops.c wraps some goop around a
VOP_READDIR - pushing the handling of the dirents to the underlying fs
method.

> 
> Note that ffs needs DIRBLKSIZ to be the same as the underlying atomic
> I/O size, or various unspecified bad things can happen in crashes. So
> you can't change what ffs is doing.
> 

Absolutely no thought in my mind about changing the size of DIRBLKSIZ in
the kernel, I do understand the implications of doing that and until
(if?) everyone has 4k sectors it probably will not change.  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 :(

> Also, I have no idea why the userland value diverged from the ffs
> value, but I doubt it's safe to change it without adding a large pile
> of compat wibble.
> 

Yep, this is why I asked :)

> Finally, we should not not not have duplicate symbol names like this.
> I guess now that we've branched I can go clean it up...
> 

That would be great - we will still have a problem with venus but at
least others won't be bitten by this weirdness.

I am thinking that maybe the best thing would be to try and get venus to
read the directory block size from the underlying file system and use
that, if I can.

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