Date: Sun, 12 Jan 1997 15:54:19 -0500 (EST) From: Charles Henrich <henrich@crh.cl.msu.edu> To: dg@root.com Cc: terry@lambert.org, freebsd-hackers@FreeBSD.ORG Subject: Re: mount -o async on a news servre Message-ID: <199701122054.PAA14676@crh.cl.msu.edu> In-Reply-To: <199701122033.MAA26261@root.com> from David Greenman at "Jan 12, 97 12:33:53 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> The two options are complimentary. i.e., "async" will get you fast file
>creates/deletes, but it doesn't stop the access time from being updated - it
>just delays it until the inode buffer needs to be reclaimed. "noatime" doesn't
> make creates/deletes any faster, but it does completely get rid of the inode
> updates when just reading the articles. Similarly, changing the update daemon
> frequency from 30 seconds to 300 seconds won't help with reducing the update
> of the access time on inodes. What will happen is that the inode buffer will
> need to be reclaimed long before 5 minutes runs out so you'll have to write
> it out much sooner anyway. It also won't help with file creates/deletes
> which happen syncronously and aren't effected by 'sync'.
Hmm.
Let me say what I feel is how a generaly large all-purpose news spool does per
day.
Create's and writes about 200k files and virtually zero directories.
Reads about 1-2 million files and sends them off to the net.
And delete's about 200k files a day (during one, hopefully, very small time
period)
A large number of reads should be satisfied out of memory cache (presuming you
fill the box with enough memory).
Setting noatime means that the duration of the sync() call in update() is
markedly less (as obviously there is 1/5th to 1/10th the work to do).
Now if I can push back the update() where it actually is pushed back (how?)
there should be a fairly large percentage of updates occuring to the same
directories, which should give me less update I/O's over the same time period.
Meaning that when reads come in that must hit a disk, the chances of hitting a
bottleneck because a update() is hitting all disks in the farm, is 10% as
likely to happen.
-Crh
Charles Henrich Michigan State University henrich@msu.edu
http://pilot.msu.edu/~henrich
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701122054.PAA14676>