Date: Wed, 29 May 1996 02:11:06 -0700 From: David Greenman <davidg@Root.COM> To: Joe Greco <jgreco@solaria.sol.net> Cc: hackers@freebsd.org Subject: Re: Breaking ffs - speed enhancement? Message-ID: <199605290911.CAA01059@Root.COM> In-Reply-To: Your message of "Tue, 28 May 1996 23:04:11 CDT." <199605290404.XAA25324@solaria.sol.net>
next in thread | previous in thread | raw e-mail | index | archive | help
>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. ... >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? You're not totally whacked out. I attempted to implement the same thing here, but got stuck with the flag still getting set somewhere/sometimes and had to drop that work for more important things. >(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). I added an option "noatime" to mount/fstab and implemented a special per-mount flag for this in the kernel. I was only interested in disabling the access time; I wanted the inode change time and modify times to still work correctly. My application, of course, was wcarchive - a machine with millions of files that spends about 1/3-1/2 of all of it's disk I/O just updating the access times in the inodes. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605290911.CAA01059>