From: Eric Anopolsky <erpo41@gmail.com>
To: Tejun Heo <tj@kernel.org>
Cc: Ric Wheeler <rwheeler@redhat.com>,
Chris Mason <chris.mason@oracle.com>,
Stephan von Krawczynski <skraw@ithnet.com>,
linux-btrfs@vger.kernel.org
Subject: Re: Some very basic questions
Date: Wed, 22 Oct 2008 15:31:48 -0600 [thread overview]
Message-ID: <1224711108.7399.12.camel@telesto> (raw)
In-Reply-To: <48FF515B.2030209@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1318 bytes --]
On Thu, 2008-10-23 at 01:14 +0900, Tejun Heo wrote:
> Ric Wheeler wrote:
> > Waiting for the target to ack an IO is not sufficient, since the target
> > ack does not (with write cache enabled) mean that it is on persistent
> > storage.
>
> FS waiting for completion of all the dependent writes isn't too good
> latency and throughput-wise tho. It would be best if FS can indicate
> dependencies between write commands and barrier so that barrier
> doesn't have to empty the whole queue. Hmm... Can someone tell me how
> much such scheme would help?
The extent of my coding for ZFS on FUSE was in this area. Solaris has a
generic ioctl to flush the write cache on a block device but Linux does
not. I wrote a few routines to detect the type of block device and flush
the cache by talking to the hardware via an ioctl.
Tests with bonnie++ on my laptop showed that throughput and metadata
operations per second were not noticeably affected by completely
flushing the write cache when necessary versus never flushing the write
cache or using any kind of IO barrier.
Caveats:
*Not every HDD is a laptop HDD.
*ZFS on FUSE got average to poor results for metadata operations per
second since it hadn't been optimized for that yet.
Maybe fancier schemes aren't necessary?
Cheers,
Eric
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 481 bytes --]
next prev parent reply other threads:[~2008-10-22 21:31 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-21 11:23 Some very basic questions Stephan von Krawczynski
2008-10-21 12:13 ` Andi Kleen
2008-10-21 14:22 ` Stephan von Krawczynski
2008-10-21 15:34 ` jim owens
2008-10-22 11:36 ` Stephan von Krawczynski
2008-10-22 12:15 ` Avi Kivity
2008-10-22 13:03 ` Ric Wheeler
2008-10-22 13:13 ` Chris Mason
2008-10-22 13:16 ` Avi Kivity
2008-10-21 13:20 ` jim owens
2008-10-21 17:01 ` Stephan von Krawczynski
2008-10-21 17:15 ` Christoph Hellwig
2008-10-21 17:31 ` Ric Wheeler
2008-10-22 12:27 ` Stephan von Krawczynski
2008-10-22 13:15 ` Chris Mason
2008-10-22 13:27 ` Ric Wheeler
2008-10-22 14:32 ` Avi Kivity
2008-10-22 14:36 ` Chris Mason
2008-10-22 14:40 ` Avi Kivity
2008-10-22 14:46 ` Ric Wheeler
2008-10-22 14:54 ` Avi Kivity
2008-10-22 15:02 ` Ric Wheeler
2008-10-22 15:13 ` Avi Kivity
2008-10-22 15:25 ` Ric Wheeler
2008-10-22 15:33 ` Chris Mason
2008-10-22 15:43 ` Avi Kivity
2008-10-22 15:54 ` Ric Wheeler
2008-10-22 18:28 ` Avi Kivity
2008-10-22 15:39 ` Avi Kivity
2008-10-22 13:52 ` Stephan von Krawczynski
2008-10-22 15:56 ` Michel Salim
2008-10-22 16:56 ` jim owens
2008-10-23 9:47 ` Stephan von Krawczynski
2008-10-22 11:40 ` Stephan von Krawczynski
2008-10-21 13:59 ` Chris Mason
2008-10-21 16:09 ` Andi Kleen
2008-10-22 11:43 ` Stephan von Krawczynski
2008-10-21 16:27 ` Stephan von Krawczynski
2008-10-21 16:59 ` Andi Kleen
2008-10-22 11:46 ` Stephan von Krawczynski
2008-10-21 17:49 ` Chris Mason
2008-10-22 12:19 ` Stephan von Krawczynski
2008-10-22 12:48 ` Jeff Schroeder
2008-10-22 14:02 ` Stephan von Krawczynski
2008-10-22 13:50 ` Chris Mason
2008-10-22 14:04 ` Matthias Wächter
2008-10-22 14:32 ` Ric Wheeler
2008-10-22 14:44 ` jim owens
2008-10-24 8:42 ` Chris Samuel
2008-10-24 8:39 ` Chris Samuel
2008-10-21 20:54 ` Eric Anopolsky
2008-10-21 22:18 ` Ric Wheeler
2008-10-22 2:29 ` Eric Anopolsky
2008-10-22 10:42 ` Ric Wheeler
2008-10-22 10:53 ` Tejun Heo
2008-10-22 12:57 ` Ric Wheeler
2008-10-22 12:57 ` Ric Wheeler
2008-10-22 13:15 ` Tejun Heo
2008-10-22 13:19 ` Chris Mason
2008-10-22 13:38 ` Ric Wheeler
2008-10-22 13:59 ` Chris Mason
2008-10-22 14:23 ` Ric Wheeler
2008-10-22 13:23 ` Ric Wheeler
2008-10-22 16:14 ` Tejun Heo
2008-10-22 16:34 ` Ric Wheeler
2008-10-23 3:59 ` Tejun Heo
2008-10-22 18:32 ` Avi Kivity
2008-10-22 19:13 ` jim owens
2008-10-22 19:22 ` Avi Kivity
2008-10-22 19:59 ` Ric Wheeler
2008-10-22 21:31 ` Eric Anopolsky [this message]
2008-10-22 21:56 ` Ric Wheeler
-- strict thread matches above, loose matches on Subject: below --
2008-10-21 17:37 calin
2008-10-21 20:08 ` jim owens
2008-10-22 7:15 ` Avi Kivity
2008-10-22 14:13 ` jim owens
2008-10-22 14:25 ` Avi Kivity
2008-10-22 14:35 dbz
2008-10-27 15:43 ` Stephan von Krawczynski
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=1224711108.7399.12.camel@telesto \
--to=erpo41@gmail.com \
--cc=chris.mason@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=rwheeler@redhat.com \
--cc=skraw@ithnet.com \
--cc=tj@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.