Date: Wed, 29 May 96 6:43:49 CDT From: Joe Greco <jgreco@solaria.sol.net> To: bde@zeta.org.au (Bruce Evans) Cc: hackers@freebsd.org Subject: Re: Breaking ffs - speed enhancement? Message-ID: <199605291143.GAA29506@solaria.sol.net> In-Reply-To: <199605290829.SAA27406@godzilla.zeta.org.au> from "Bruce Evans" at May 29, 96 06:29:49 pm
next in thread | previous 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. Nobody's storing mail on the news spool disks of my news servers. (As a per-mount flag, it is easy to be selective). > Changes to atimes are written to the disk asynchronously, except for > utimes(2), so the bandwidth loss is not huge. I see that it's written asynchronously. I knew that even before inspecting the code. That's why my poor reader machines go totally freaking out of their minds for a few seconds every half minute or so.. (disk lights go solid on) > 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 don't know of anything here that uses utimes()... pretty pointless within software that really doesn't care ;-) Any ideas on how to help the thrashing problem? > 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. You might need to ;-) > >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. Oooo that's a good point, I was thinking of not doing st_mtime's for NOV data. However, everywhere else in news is pretty much write once read many. I am not concerned tooooo much about the write once. It is the read many that kills. A million (actually probably twice that these days) articles on line, three hundred nnrpd clients, over a hundred articles per second requested, ummmmmmm... plus five articles per second being written to the spool.. we now have lots of moderately random data being needlessly written back to disk when the reality is that the IO system is already saturated. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605291143.GAA29506>