memory inconsistencies with OpenAFS on FreeBSD

Kostik Belousov kostikbel at gmail.com
Sat Aug 28 08:35:59 UTC 2010


On Sat, Aug 28, 2010 at 12:28:51AM -0400, Benjamin Kaduk wrote:
> Hi all,
> 
> I've been working to make the OpenAFS network filesystem client usable on 
> FreeBSD; it's currently in a mostly-working state. 
> ( http://www.openafs.org/ ; I have a hackish packaging of it as a FreeBSD 
> port at http://web.mit.edu/freebsd/openafs/openafs.shar .  Note that it is 
> broken on recent -current since it it fails to register its syscall 
> properly; this is fixed in git master pending an update to 
> syscalls.master.)
> 
> Normal file operations from a shell work okay, I can write and 
> edit a file with vi, etc.; copying /usr/src into and out of AFS proceeds 
> nicely.
> However, if I proceed to the standard lazy man's filesystem stress test, 
> buildworld, things don't get very far:
> >>>stage 1.1: legacy release compatibility shims
> [...]
> ===> tools/build (obj,includes,depend,all,install)
> [...]
> cc -O2 -pipe -std=gnu99 
> -I/afs/zone.mit.edu/user/kaduk/build/obj/afs/zone.mit.
> edu/user/kaduk/build/tmp/legacy/usr/include -c 
> /afs/zone.mit.edu/user/kaduk/buil
> d/tools/build/dummy.c
> building static egacy library
> *** Signal 11
> 
> I also don't seem to be able to run executables from AFS:
> freebuild# ./my_mmap test4
> elf_load_section: truncated ELF file
> Abort
This sounds very much as missed vnode_pager_setsize() calls.
VM tracks the file size as vnode vmobject size separately.
I think this was done for historical reasons, but also it
allows to not traverse the vop stack calling VOP_GETATTR each
time when size is needed.

> 
> 
> Trying to dig a bit deeper and get a smaller test case, rwatson suggested 
> that I look at mmap-ing a file and reading/writing from it. I wrote a 
> small test program, and reading from the mmaped file works okay. However, 
> writing to the mmap-ed file does not seem to take effect (though my test 
> program does modify the target file on local disk).
> 
> (Also, when I do silly things like try to access unmapped memory which 
> ought to generate a core dump, I get on the console:
> freebuild kernel: Failed to write core file for process my_mmap (error 
> 14))
> 
> Where should I be looking to track down what's going on?
> 
> I note that we do provide our own getpages and putpages vops, and this 
> code hasn't been particularly loved since the FreeBSD 4.x days.
> 
> Thanks for any suggestions,
> 
> Ben Kaduk
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20100828/bf630ade/attachment.pgp


More information about the freebsd-fs mailing list