Date: Mon, 4 Mar 1996 11:19:00 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: monboso@masternet.it, freebsd-hackers@FreeBSD.ORG Subject: Re: xfs not working properly Message-ID: <199603041819.LAA06257@phaeton.artisoft.com> In-Reply-To: <199603040033.LAA09216@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Mar 4, 96 11:03:29 am
next in thread | previous in thread | raw e-mail | index | archive | help
[ ... re: using xfs ... ] > Please get your facts straight here. The FreeBSD NFS server is not "much > slower", the problem is that the _DOS_clients_ are "much slower". The DOS clients are generally broken, unless they have local cache, but the FreeBSD NFS server is also "much slower". As I pointed out in my previous posting, since the protocol is stateless, effectively the vnode is looked up and freed on each reference. Since the cache in FreeBSD is vnode/extent based, not device/extent based, this results in basically *zero* cache hits. There are several lame ways around this that really break FreeBSD. I won't go into them because I don't want to see them implemented. There is a lame side effect of a correct change that would mask the problem somewhat (if the name cache lookup were moved out of the per FS code, as it should be, and cache entries were treated as vnode reference instances, then the vnode would stay in cache). And there is the real fix (go to device/extent based caching and clean up most of vfs_subr.c, especially the vclean crap), which introduces a 2G limit on logical device size instead of just a 2G limit on open file size. Unless we eat the additional overhead for 64 bit offsets in the VM systems. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603041819.LAA06257>