Date: Wed, 29 May 1996 18:29:49 +1000 From: Bruce Evans <bde@zeta.org.au> To: hackers@freebsd.org, jgreco@solaria.sol.net Subject: Re: Breaking ffs - speed enhancement? Message-ID: <199605290829.SAA27406@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>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. Things like checking for mail actually depend on it. Changes to atimes are written to the disk asynchronously, except for utimes(2), so the bandwidth loss is not huge. News file systems probably lose more than most by thrashing the inode cache (another problem) so that async inode writes are almost sync. And perhaps something in your news software uses utimes() a lot? Once per (small) file creation is a lot. You get one or two sync updates for the creat/write/close and one sync update for utimes() - about 100% or 50% overhead. I think atimes should be cached (or permanently allocated) independently of their inodes. It would be reasonable to cache a few hundred thousand of them in memory. >Am I just totally whacked out, or is this perhaps a reasonable thing to do, Only for special file systems. >(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). You don't gain much by not changing the mtime/ctime. They usually change together with the file size and the file size must be written. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605290829.SAA27406>