Date: Sat, 28 Aug 2010 11:24:53 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Benjamin Kaduk <kaduk@mit.edu> Cc: freebsd-fs@freebsd.org Subject: Re: memory inconsistencies with OpenAFS on FreeBSD Message-ID: <20100828082453.GG2396@deviant.kiev.zoral.com.ua> In-Reply-To: <alpine.GSO.1.10.1008272351061.9337@multics.mit.edu> References: <alpine.GSO.1.10.1008272351061.9337@multics.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkx4x9UACgkQC3+MBN1Mb4hfWgCg8XBS8Xp6xBovk09983KFTAKG DN8AnR4sYmguJR425zvFVNPAcbuYudMQ =eDx5 -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100828082453.GG2396>