From owner-freebsd-fs Wed Mar 22 16:17:37 2000 Delivered-To: freebsd-fs@freebsd.org Received: from fLuFFy.iNt.tElE.dK (fw1.inet.tele.dk [193.163.158.4]) by hub.freebsd.org (Postfix) with ESMTP id B20CC37C2B9; Wed, 22 Mar 2000 16:17:17 -0800 (PST) (envelope-from pedophile@INT.TELE.DK) Received: from localhost (pedophile@localhost) by fLuFFy.iNt.tElE.dK (8.9.3/8.9.3) with SMTP id BAA86413; Thu, 23 Mar 2000 01:17:06 +0100 (CET) (envelope-from pedophile@INT.TELE.DK) X-Authentication-Warning: fLuFFy.iNt.tElE.dK: pedophile owned process doing -bs Date: Thu, 23 Mar 2000 01:17:06 +0100 (CET) From: FREENIX IS OVERRATED Reply-To: FreeBSD-abusers@netscum.dk To: Matthew Dillon Cc: current@FreeBSD.ORG, fs@FreeBSD.ORG Subject: Re: FreeBSD random I/O performance issues In-Reply-To: Message-ID: X-Pedophile: BARRY BOUWSMA IS AN OFFENSIVE USENET PEDOPHILE MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 2395 Sep 1993, Matthew Dillon wrote: > It is perfectly ok for dirty blocks to remain in the buffer cache. In > fact, it's *optimal* to leave them in the buffer cache as long as the > buffer cache does not get saturated with them. The buffer cache is > perfectly capable of clustering delayed writes. Also, the filesystem > syncer comes along every 30 seconds or so anyway and flushes everything > out. > > What the write-behind code tries to do is to prevent the buffer cache > from being saturated with dirty buffers and to smooth out disk write > I/O. It makes the assumption that write-behind data is not typically > accessed by the program immediately after being written -- an assumption > that winds up being incorrect in the DBM case you tested and resulting > in stalls due to the buffer / VM pages being locked during the write I/O. > The stalls are *not* due to the I/O itself but instead are due to side > effects of the I/O being in-progress. And that sounds a heck of a lot like what those of us who have been running INN news swervers with 1,1GB size text history files on 2.whazzit (now dead, may it rest in pieces widely-scattered) and later have seen. You should have forgotten that a couple months or so ago, I wrote to one of these lists to ask why I was getting only about 50-70% availability as my 1.5+MD5-based-dbz innd was stuck in ufslck2 during these every-30-seconds syncs. The .hash and .index files from this, which are comparable to the dbm (dbz) files being typically 125MB and 85MB or so, this under 3.4-STABLE. Well, I've meant to get around to trying 4.0 on it, and Real Soon Now I will, but I wanted to relate my experiences in turning traitor, a heretic who has left the fold, deserving to be ridden out of town on a rail and stuff, which sounds like a lot of fun. I tried NetBSD. NetBSD (at least the development now 1.4V version) has trickle syncing, which seems to work quite well when having to cope with these rather large database files, keeping a full 14 days of message IDs from a full news feed. Without really tuning anything, after a bit of time, the time needed to do history lookups drops to microseconds, and as long as a `sync' isn't needed, innd doesn't get stuck. Theoretically, a sync, where you are in fact seeking rather wildly over the disk to update these files, happens once a day at expiry. Depending on the speed of the drive (and I haven't optimized this at all, using a single drive for OS, logs, history, and part of spool, with a second drive for the rest of the spool, far from an ideal setup), this seems to mean only a few minutes of downtime. Actually building the new .index and .hash files goes quite a bit faster, like by a factor of 3 to 4, so clearly the update of these files during the `sync' could stand improved sorting. I wouldn't complain a bit if you were to steal mercilessly from the NetBSD k0deZ to incorporate trickle sync (if something comparable is not already in place) since that seems to make a world of difference for those of us using long-outdated INN code and who want to have bigger history file sizes than our shriveling Freenix members. (What kills me now is that I'm using a single drive to hold the news spool apart from a small overflow, so while time spent accessing this history database is way down, the time actually spent hopping around the disk to write (and read, for our sluggish peers) articles has skyrocketed. The box I'll try 4.0 on has a separate disk pack that is far faster under NetBSD. Test boxen, eh?) There. I've confessed. It feels really good. Now have at me. Naturally, since I haven't followed this discussion closely, you may be talking about something completely different, but I did want to mention generally improved (yet not totally perfect) performance with huge INN database files and NetBSD's trickle syncing. Now, go out and steal some k0deZ, okay? barry bouwsma, tele danMerika internet -- *** This was posted with the express permission of *** ****************************************************** ** HIS HIGHNESS KAAZMANN LORD AND MASTER OF USENET ** ****************************************************** ********* We are simple servants of his will ********* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message