Date: Thu, 19 Apr 2001 14:00:36 -0700 (PDT) From: wpaul@FreeBSD.ORG (Bill Paul) To: crossd@cs.rpi.edu (David E. Cross) Cc: jkh@osd.bsdi.com, stable@FreeBSD.org, developers@FreeBSD.org, crossd@cs.rpi.edu Subject: Re: FreeBSD 4.3-RC5 now on ftp.freebsd.org Message-ID: <20010419210036.5A53A37B424@hub.freebsd.org> In-Reply-To: <200104192001.QAA60154@cs.rpi.edu> from "David E. Cross" at "Apr 19, 2001 04:01:16 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> Yes, I would agree with that. I needed to hack the scripts here to mount_mfs > and cp files back and forth a few times to get everything to work correctly, > but it does work without panic-ing the system. I can post patches if people > would find that helpfull. > > (I am still working on ypserv as well, the problems run very deep in that > code. Once you know where to look they start popping up all over the place. > Just as a sample cosider the code: > > qhead.cqh_head->dbptr->key = key->data; > > Where "key" is a DBT* that was passed back from the berkley db routines... > now consider a few more database requests come in before that record is accessed again and all of a sudden 'key' isn't pointing at what you originally set it > to.) Uh. Look closer. No no, closer. The key/size members in the cached database handle are used by the first/next routines to keep an eye on where we are in the database so we can match a database handle with an ongoing first/next enumeration request. (That is, where the client does a yp_first() and then a series of yp_next()s to dump out all of the entries in a map. Things like getpwent() and getgrent() do this, and it gets *really* slow if you have to start from the top and linear search down for each yp_next() request, which is what you'd have to do since the Berkeley DB hash database method doesn't let you position the 'cursor' at arbitrary locations. This trick lets us say: "Hey! This is the same handle we used for the last yp_next() request, and it's positioned at the right place in the database for us to pick up where we left off. Let's use this handle again.") The key pointer remains valid up until the next request is made, which could be a yp_first_record(), yp_next_record() or yp_get_record(). - yp_first_record(): we set the key pointer to the current key - yp_next_record: we set the key pointer to the current key - yp_get_record(): we set the key pointer to NULL Every time we do a new database access, we update the key pointer. It can never point off into the weeds because it never becomes stale. I admit, the optimization is grody. Had I used the btree database method, this wouldn't have been necessary, but something told me not to do that. If you can prove that using the btree method would be faster, you can re-write the yp_dblookup.c module to use it. -Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010419210036.5A53A37B424>