linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bernd Schubert <bernd.schubert@fastmail.fm>
To: Roger Heflin <rogerheflin@gmail.com>, Weedy <weedy2887@gmail.com>
Cc: Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: Off-Topic Write cache disabling?
Date: Wed, 04 Feb 2015 13:45:33 +0100	[thread overview]
Message-ID: <54D2146D.8020108@fastmail.fm> (raw)
In-Reply-To: <CAAMCDedvF+Nv9LYqM7Ddgg2xMQKtgQDntOsG0krxWCV4H+zQmA@mail.gmail.com>



On 02/03/2015 07:49 PM, Roger Heflin wrote:
> In general if you completely disable write caching things will likely
> be unusable.    When I have benchmarked things attempting to turn off
> write cache performance has been mostly unusable.
> 
> I usually change /etc/sysctl.conf and change these entries to control
> the amount of dirty cache.
> 
> vm.dirty_background_bytes = 25000000
> vm.dirty_bytes = 50000000
> 
> That says max dirty allowed is 50mb, and it syncs down to 25mb when it syncs.

Er, where do you have this from? 
dirty_background_bytes and dirty_bytes are more about non-blocking and 
blocking dirty writes. And about the amount of dirty data that triggers 
it (i.e. there is no need to flush temporary file data to disk if files
get immediately deleted after writing them)
 
linux/Documentation/sysctl/vm.txt

==============================================================

dirty_background_bytes

Contains the amount of dirty memory at which the background kernel
flusher threads will start writeback.

Note: dirty_background_bytes is the counterpart of dirty_background_ratio. Only
one of them may be specified at a time. When one sysctl is written it is
immediately taken into account to evaluate the dirty memory limits and the
other appears as 0 when read.

==============================================================


==============================================================

dirty_bytes

Contains the amount of dirty memory at which a process generating disk writes
will itself start writeback.

Note: dirty_bytes is the counterpart of dirty_ratio. Only one of them may be
specified at a time. When one sysctl is written it is immediately taken into
account to evaluate the dirty memory limits and the other appears as 0 when
read.

Note: the minimum value allowed for dirty_bytes is two pages (in bytes); any
value lower than this limit will be ignored and the old configuration will be
retained.

==============================================================



Bernd

  parent reply	other threads:[~2015-02-04 12:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-03 17:45 Off-Topic Write cache disabling? Weedy
2015-02-03 18:49 ` Roger Heflin
2015-02-03 19:16   ` Alireza Haghdoost
2015-02-04  0:38     ` Roger Heflin
2015-02-04  5:00   ` Weedy
2015-02-04 12:45   ` Bernd Schubert [this message]
2015-02-04 12:46 ` Bernd Schubert
2015-02-05  4:47 ` NeilBrown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54D2146D.8020108@fastmail.fm \
    --to=bernd.schubert@fastmail.fm \
    --cc=linux-raid@vger.kernel.org \
    --cc=rogerheflin@gmail.com \
    --cc=weedy2887@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).