Date: Fri, 17 Jul 2009 11:10:43 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: Anonymous <swell.k@gmail.com>, Rick Macklem <rmacklem@freebsd.org>, freebsd-current@freebsd.org Subject: Re: [newnfs/client] -alldirs: listing files consumes too much memory Message-ID: <20090717081043.GP55190@deviant.kiev.zoral.com.ua> In-Reply-To: <Pine.GSO.4.63.0907162005540.9851@muncher.cs.uoguelph.ca> References: <861vogcyp4.fsf@gmail.com> <Pine.GSO.4.63.0907162005540.9851@muncher.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
--EGjwyTcQXITbA3JU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 16, 2009 at 08:12:38PM -0400, Rick Macklem wrote: >=20 >=20 > On Thu, 16 Jul 2009, Anonymous wrote: >=20 > >Let's create 335 empty files in /blah and try to list them over nfsv3. > > > ># uname -vm > >FreeBSD 8.0-BETA1 #0: Sat Jul 4 03:55:14 UTC 2009 =20 > >root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > > > ># mkdir /blah > ># (while [ $((i+=3D1)) -le 334 ]; do : >/blah/foo_$i; done) > ># echo / -alldirs >/etc/exports > ># /etc/rc.d/nfsd onestart > ># mount -t newnfs -o nfsv3 0:/blah /mnt > > > Well, this turns out more interesting than I expected. The problem occurs > when there is a large directory "at the mount point only". If you: > # mount -t newnfs -o nfsv3 0:/ /mnt > # cd /mnt/blah > # ls > - it works. >=20 > When the large directory is at the mount point, it reads the first > block normally but... it then thinks all subsequent blocks are already > in the buffer cache. ie. They come back from getblk() with B_CACHE > already set??? (It then just loops getting blocks forever, since it > won't see the eof if it doesn't try and read from the server.) >=20 > Anyone happen to have a clue why that would happen? Why would blocks > on a mount point vnode behave differently than others. >=20 > Well, at least it's easy to reproduce, so I can keep poking around > with it, rick. Without looking too hard into it, could it be due to read-ahead ? --EGjwyTcQXITbA3JU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpgMgIACgkQC3+MBN1Mb4jcIACcDmqiM/e3fAniOaokeaUcekL0 4gUAoLbPbWqqQWo7iGlNUUKXkS8Yh457 =aqwQ -----END PGP SIGNATURE----- --EGjwyTcQXITbA3JU--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090717081043.GP55190>