mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Helge Hafting <helgehaf@aitel.hist.no>
To: Tim Connors <tconnors@astro.swin.edu.au>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Delaying writes to disk when there's no need
Date: Sun, 30 Mar 2003 19:38:02 +0200	[thread overview]
Message-ID: <20030330173802.GA5427@hh.idb.hist.no> (raw)
In-Reply-To: <200303281018.h2SAIxq29603@tellurium.ssi.swin.edu.au>

On Fri, Mar 28, 2003 at 09:18:59PM +1100, Tim Connors wrote:
> In linux.kernel, you wrote:
> > Helge Hafting (helgehaf@aitel.hist.no) wrote:
> >> Erik Hensema wrote:
> >>> In all kernels I've tested writes to disk are delayed a long time even when
> >>> there's no need to do so.
> >>> 
> >> Short answer - it is supposed to do that!
> >> 
> >>> A very simple test shows this: on an otherwise idle system, create a tar of
> >>> a NFS-mounted filesystem to a local disk. The kernel starts writing out the
> >>> data after 30 seconds, while a slow and steady stream would be much nicer
> >>> to the system, I think.
> 
> Agreed. We have a cluster which is writing on average something like
> 20 Megs/sec/node. We had to lower the write threshold from 30% to 0%,
> because with the constant writing, linux will buffer it for 30 secs,
> fill up RAM, try to empty the write-cache, stall, wash, rinse,
> repeat. Because it was being filled up at roughly the rate it was
> being emptied, once it got 30% behind, there was no catching up, so
> the realtime system would lose data. Ouch.
> 
Nothing can help you if you're getting input at the rate you
can write it.  You need ability to write at least somewhat faster
no matter how buffering is done.

> >> You're wrong then.  There's no need for a slow steady stream, why do
> >> you want that.  Of course you can set up cron to run sync at
> >> regular (short) intervals to achieve this.
> 
> Last time I checked, cron had 1 minute resolution.

If you need to sync more often than once per minute, consider
this shellscript:
for ((;;)) ; do sleep 1 ; sync ; done

[...]
> Helge's comment about /tmp files and rewriting files multiple times:
> in real life, how often does this happen? How often do you overwrite
> one file many times in 30 seconds?

_Every_ time you write a file in chunks not perfectly aligned
on block boundaries. 

> The occasional 20 kilobyte /tmp
> file perhaps, but I doubt it matters in real life. In real life, when
> writing to disk constantly (not just scientific applications - I
> believe this happens in the real world too!), waiting for 30 seconds
> is a liability!

Only if that 30-second wait makes linux buffer more than it can handle.
That may indeed be a problem, but buffering up _some_ data
before writing is still a good idea.

Helge Hafting

  reply	other threads:[~2003-03-30 17:24 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20030326204012$188c@gated-at.bofh.it>
     [not found] ` <20030327091007$22a5@gated-at.bofh.it>
     [not found]   ` <20030327113014$37b4@gated-at.bofh.it>
2003-03-28 10:18     ` Tim Connors
2003-03-30 17:38       ` Helge Hafting [this message]
2003-03-26 20:31 Erik Hensema
2003-03-27  9:06 ` Helge Hafting
2003-03-27 11:22   ` Erik Hensema
2003-03-28 23:12 ` Pavel Machek
2003-03-31 12:00   ` Erik Hensema
2003-03-31 13:42     ` Helge Hafting
2003-03-31 14:45       ` Oliver Neukum
2003-03-31 22:02       ` Nick Piggin
2003-03-31 22:22         ` Chris Friesen
2003-03-31 22:35           ` Nick Piggin
2003-03-31 22:51             ` John Bradford
2003-03-31 22:58               ` Nick Piggin
2003-03-31 22:45         ` Andrew Morton
2003-03-31 23:03           ` Nick Piggin
2003-03-31 23:32           ` Ingo Oeser
2003-04-01  0:02             ` Andrew Morton
2003-04-01  0:43           ` Daniel Pittman
2003-04-01  1:09             ` Andrew Morton
2003-04-01  1:34               ` Daniel Pittman
2003-04-01  1:45                 ` Andrew Morton
     [not found]               ` <3E88EB3D.6020409@cyberone.com.au>
2003-04-01  1:39                 ` Andrew Morton

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=20030330173802.GA5427@hh.idb.hist.no \
    --to=helgehaf@aitel.hist.no \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tconnors@astro.swin.edu.au \
    /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

all inboxes | Powered by JetHome®