On Tue, Nov 20, 2018 at 08:25:38PM +1030, Brett Lymn wrote: > I am guessing that not many people use coda (or they just haven't > complained) as it seems like the coda kernel support has suffered some > bit-rot. Trying to access a coda file system on -current results in a > couple of KASSERTs firing - the first is easy, we need to lock the vnode > on readdir but after doing that there is a check in ufs_readwrite.c to > ensure the vnode is either a VDIR or VLNK type, neither of which is true > for coda because the whole coda file system is contained in a regular > file on the host file system so the vnode type is VREG. The following > patch makes coda work for me. I don't think that manipulating the vnode > type is really great but a lesser evil than trying to create a duplicate > of the ufs readdir code and also not as bad as removing the KASSERTs > which are useful sanity checks in the majority of use cases.
So I have no immediate comment on the patch but I'd like to understand better what it's doing -- the last time I crawled around in it (probably 7-8 years ago) it appeared to among other things have an incestuous relationship with ufs_readdir such that if you tried to use anything under than ffs as the local container it would detonate violently. But I never did figure out exactly what the deal was other than it was confusing and seemed to violate a lot of abstractions. Can you clarify? It would be nice to have it working properly and stuff like the above is only going to continue to fail in the future... -- David A. Holland dholl...@netbsd.org