[mythtv-users] pdflush is killing me
adeffs.mythtv at gmail.com
Wed Feb 7 15:08:44 UTC 2007
On 2/7/07, Dan Ritter <dsr-myth at tao.merseine.nu> wrote:
> On Wed, Feb 07, 2007 at 08:39:59AM -0500, Steven Adeff wrote:
> > having seen pdflush run while observing top (not knowing if it was
> > causing any actual issues...), I've taken an interest in what you've
> > written here. Would you mind elaborating on what this does for people
> > like me that don't know what that means?
> Linux uses any spare RAM you might have for caching disk reads
> and writes. RAM is, of course, much faster than disk, and
> writing sequentially to disk is faster than writing to random
> locations. So, the longer you can go between an application
> trying to write some data and actually doing that write to disk,
> the better your performance will be.
> Unfortunately, data that's in the cache but not written to disk
> will disappear in a power glitch. Also, applications are always
> asking for more memory, and the cached data has a lower priority
> claim. pdflush is a kernel-controlled process that takes that
> dirty (i.e. written to memory but not yet on disk, as opposed to
> clean, which is the same on disk and in memory) information and
> sends it all to disk. It can be tuned to do so more or less
> often, but the usual default is 5 seconds.
> The kernel parameter dirty_writeback_centisecs controls the time
> between pdflush flushes. dirty_expire_centisecs controls the
> minimum age of a dirty page before pdflush is allowed to flush
> it. (That guarantees that some caching happens.)
gotcha. So in our case, where large amounts of writes are occuring
over a long period of time (like recording 3 one hour HDTV shows), we
want don't need this caching, and waiting to long may make writing in
bursts actually slower than writing in a constant stream?
or am I understanding the need to change these values wrongly?
Before you ask, read the FAQ!
then search the Wiki, and this list,
Mailinglist etiquette -
More information about the mythtv-users