From owner-freebsd-hackers Tue May 28 21:02:35 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA01775 for hackers-outgoing; Tue, 28 May 1996 21:02:35 -0700 (PDT) Received: from anacreon.sol.net (anacreon.sol.net [206.55.64.116]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA01770 for ; Tue, 28 May 1996 21:02:30 -0700 (PDT) Received: from solaria.sol.net (solaria.sol.net [206.55.65.75]) by anacreon.sol.net (8.6.12/8.6.12) with ESMTP id XAA08000 for ; Tue, 28 May 1996 23:02:21 -0500 Received: from localhost by solaria.sol.net (8.5/8.5) id XAA25324; Tue, 28 May 1996 23:04:13 -0500 From: Joe Greco Message-Id: <199605290404.XAA25324@solaria.sol.net> Subject: Breaking ffs - speed enhancement? To: hackers@freebsd.org Date: Tue, 28 May 96 23:04:11 CDT X-Mailer: ELM [version 2.4dev PL65] MIME-Version: 1.0 Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Well, I finally went and did it. :-) I added a flag to mount to tell FFS not to worry about the datestamps on inodes. Intended goal: on a busy news server with a hundred articles per second going out the door, I felt that it might not be reasonable to try to write the st_atime changes back out to the disk. Basically, no one gives a rip, and that's a lotta writes that I don't have time or disk bandwidth to do. I haven't done any benchmarks. However, I did see the machine peak at 9.7 articles per second, beating the previous 7.6, which might have been due to this change, or maybe not. Am I just totally whacked out, or is this perhaps a reasonable thing to do, given that I'd really rather not have to absorb the extra write activity on the filesystems... does anybody else perceive any value along these lines of thought? (I don't pretend to think my patches are complete or correct, btw, I just wanted to see how badly I could mess things up. In particular due to the way I did things, file dates don't get set on a create, either, so all my files are dated 1969. The "ideal" solution might set the date correctly on a create, but not touch it on a modify or a read). ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847