From: "Ted Ts'o" <tytso@mit.edu>
To: Charles Samuels <charles@cariden.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Queuing of disk writes
Date: Sun, 3 Apr 2011 22:02:35 -0400 [thread overview]
Message-ID: <20110404020235.GA4706@thunk.org> (raw)
In-Reply-To: <201104011259.53936.charles@cariden.com>
On Fri, Apr 01, 2011 at 12:59:53PM -0700, Charles Samuels wrote:
>
> I have an application that is writing large amounts of very
> fragmented data to harddrives. That is, I could write megabytes of
> data in blocks of a few bytes scattered around a multi-gigabyte
> file.
Doctor, doctor, it hurts when I do this.... any way you can avoid
doing this? What is your application doing at the high level.
> Obviously, doing this causes the harddrive to seek a lot and takes a
> while. From what I understand, if I allow linux to cache the
> writes, it will fill up 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.
This is one way to avoid some of the seeks, yes.
> However, there's a major cost in allowing the write cache to fill:
> fsync takes *ages*. What's worse is that while fsync is proceeding,
> it seems *all* disk operations in the OS are blocked. This is really
> terrible for performance of my application: my application might
> want to do some reads (i.e. from another thread) from the disk
> preempting the fsync temporarily. It's also really terrible for me,
> because then my workstation becomes unresponsive for several
> minutes.
Who or what is calling fsync()? Is it being called by your
application because you want to initiate writeout? Or is it being
called by some completely unrelated process?
If it is being called by the application, one thing you can do is to
use the Linux-specific system call sync_file_range(). You can use
this to do asynchronous data flushes of the file, and control which
range of bytes are written out, which can also help avoid flooding the
disk with too many write requests.
If the fsync() is being called by some other process, then yeah, you
have a problem. What I'd suggest is using a separate partition and
file system for this application of yours which needs to write
megabytes and megabytes of data at random locations in this
multi-gigabyte file of yours....
- Ted
next prev parent reply other threads:[~2011-04-04 13:53 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
2011-04-01 20:39 ` Alan Cox
2011-04-04 2:02 ` Ted Ts'o [this message]
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=20110404020235.GA4706@thunk.org \
--to=tytso@mit.edu \
--cc=charles@cariden.com \
--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