public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Charles Samuels <charles@cariden.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Queuing of disk writes
Date: Fri, 1 Apr 2011 13:34:24 -0700	[thread overview]
Message-ID: <201104011334.24182.charles@cariden.com> (raw)
In-Reply-To: <20110401211049.6c183cfc@lxorguk.ukuu.org.uk>

On Friday, April 01, 2011 1:10:49 pm Alan Cox wrote:
> > the kernel's write cache, and then consequently the disk drive's DMA
> > queue. As a result of that, the harddrive can pick the correct order to
> > do these writes, significantly reducing seek times.
> 
> Well that depends a lot on the data, if its very scattered and random it
> may not help much.
Generally 64KiB - I don't know disk geometry, but I guess that's a lot smaller 
than a cylinder.

But I don't really care about throughput (much), I care more about my 
application not blocking everything while the fsync happens.

> 
> > And yes, I *know* fsync is a poor method to determine if data is actually
> > committed to something non-volatile. :)
> 
> fsync/fdatasync should at least make sure it hit the disk. If barriers
> are enabled the rest too.
> 
> What file system are you using - some of the file systems have serious
> limits in this are around fsync and ordering and you may be hitting those.

I've seen this on ext3, ext4, and XFS. Reiser3 not so much. I've also 
convinced my users to use write-backed cache. They're Enterprise customers and 
have loads of money to spend on hardware, such as Warp Cores.

> 
> The ultima answer is probably an SSD of course 8)
Well, that would solve the throughput, but it doesn't solve the blocking!

Charles

  reply	other threads:[~2011-04-01 20:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-01 19:59 Queuing of disk writes Charles Samuels
2011-04-01 20:10 ` Alan Cox
2011-04-01 20:34   ` Charles Samuels [this message]
2011-04-01 20:39     ` Alan Cox
2011-04-04  2:02 ` Ted Ts'o
2011-04-04 17:50   ` Charles Samuels
2011-04-04 17:54     ` david
2011-04-05 19:37     ` Ted Ts'o

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=201104011334.24182.charles@cariden.com \
    --to=charles@cariden.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    /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