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
--41nqFSEcPhzBz76I Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 28, 2010 at 12:28:51AM -0400, Benjamin Kaduk wrote: > Hi all, >=20 > I've been working to make the OpenAFS network filesystem client usable on= =20 > FreeBSD; it's currently in a mostly-working state.=20 > ( http://www.openafs.org/ ; I have a hackish packaging of it as a FreeBSD= =20 > port at http://web.mit.edu/freebsd/openafs/openafs.shar . Note that it i= s=20 > broken on recent -current since it it fails to register its syscall=20 > properly; this is fixed in git master pending an update to=20 > syscalls.master.) >=20 > Normal file operations from a shell work okay, I can write and=20 > edit a file with vi, etc.; copying /usr/src into and out of AFS proceeds= =20 > nicely. > However, if I proceed to the standard lazy man's filesystem stress test,= =20 > buildworld, things don't get very far: > >>>stage 1.1: legacy release compatibility shims > [...] > =3D=3D=3D> tools/build (obj,includes,depend,all,install) > [...] > cc -O2 -pipe -std=3Dgnu99=20 > -I/afs/zone.mit.edu/user/kaduk/build/obj/afs/zone.mit. > edu/user/kaduk/build/tmp/legacy/usr/include -c=20 > /afs/zone.mit.edu/user/kaduk/buil > d/tools/build/dummy.c > building static egacy library > *** Signal 11 >=20 > 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. >=20 >=20 > Trying to dig a bit deeper and get a smaller test case, rwatson suggested= =20 > that I look at mmap-ing a file and reading/writing from it. I wrote a=20 > small test program, and reading from the mmaped file works okay. However,= =20 > writing to the mmap-ed file does not seem to take effect (though my test= =20 > program does modify the target file on local disk). >=20 > (Also, when I do silly things like try to access unmapped memory which=20 > ought to generate a core dump, I get on the console: > freebuild kernel: Failed to write core file for process my_mmap (error=20 > 14)) >=20 > Where should I be looking to track down what's going on? >=20 > I note that we do provide our own getpages and putpages vops, and this=20 > code hasn't been particularly loved since the FreeBSD 4.x days. >=20 > Thanks for any suggestions, >=20 > 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" --41nqFSEcPhzBz76I Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkx4x9UACgkQC3+MBN1Mb4hfWgCg8XBS8Xp6xBovk09983KFTAKG DN8AnR4sYmguJR425zvFVNPAcbuYudMQ =eDx5 -----END PGP SIGNATURE----- --41nqFSEcPhzBz76I--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100828082453.GG2396>