LKML Archive on
help / color / mirror / Atom feed
From: Robert Hancock <>
To: Jens Axboe <>
Cc: Tejun Heo <>,
	linux-kernel <>,,,, Jeff Garzik <>,
	Alan Cox <>, Mark Lord <>
Subject: Re: libata FUA revisited
Date: Mon, 19 Feb 2007 13:46:03 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Jens Axboe wrote:
> But we can't really change that, since you need the cache flushed before
> issuing the FUA write. I've been advocating for an ordered bit for
> years, so that we could just do:
> normal operation -> barrier issued -> write barrier FUA+ORDERED
>  -> normal operation resumes
> So we don't have to serialize everything both at the block and device
> level. I would have made FUA imply this already, but apparently it's not
> what MS wanted FUA for, so... The current implementations take the FUA
> bit (or WRITE FUA) as a hint to boost it to head of queue, so you are
> almost certainly going to jump ahead of already queued writes. Which we
> of course really do not.

I think that FUA was designed for a different use case than what Linux 
is using barriers for currently. The advantage with FUA is when you have 
"before barrier", "after barrier" and "don't care" sets, where only the 
specific things you care about ordering are in the before/after barrier 
sets. Then you can do this:

Issue all before barrier requests with FUA bit set
Wait for all those to complete
Issue all after barrier requests with FUA bit set
Wait for all those to complete

Meanwhile a bunch of "don't care" requests could be going through on the 
device in the background. If we could do this, then I think there would 
be an advantage. Right now, it just saves a command to the drive when 
we're flushing on the post-barrier writes.

This would only be efficient with NCQ FUA, because regular FUA forces 
the requests to complete serially, whereas in this case we don't really 
care what order the individual requests finish, we just care about the 
ordering of the pre vs. post barrier requests.

> I'm not too nervous about the FUA write commands, I hope we can safely
> assume that if you set the FUA supported bit in the id AND the write fua
> command doesn't get aborted, that FUA must work. Anything else would
> just be an immensely stupid implementation. NCQ+FUA is more tricky, I
> agree that it being just a command bit does make it more likely that it
> could be ignored. And that is indeed a danger. Given state of NCQ in
> early firmware drives, I would not at all be surprised if the drive
> vendors screwed that up too.
> But, since we don't have the ordered bit for NCQ/FUA anyway, we do need
> to drain the drive queue before issuing the WRITE/FUA. And at that point
> we may as well not use the NCQ command, just go for the regular non-NCQ
> FUA write. I think that should be safe.

Aside from the issue above, as I mentioned elsewhere, lots of NCQ drives 
don't support non-NCQ FUA writes..

Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from
Home Page:

  reply	other threads:[~2007-02-19 19:46 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.S80SRyQbD/>
2007-02-12  5:47 ` libata FUA revisited Robert Hancock
     [not found] ` <fa.Q/>
2007-02-13  0:23   ` Robert Hancock
2007-02-13 15:20     ` Tejun Heo
2007-02-14  0:07       ` Robert Hancock
2007-02-14  0:50         ` Tejun Heo
2007-02-15 18:00           ` Jens Axboe
2007-02-19 19:46             ` Robert Hancock [this message]
2007-02-21  8:37               ` Tejun Heo
2007-02-21  8:46                 ` Jens Axboe
2007-02-21  8:57                   ` Tejun Heo
2007-02-21  9:01                     ` Jens Axboe
2007-02-22 22:44                     ` Ric Wheeler
2007-02-22 22:40                   ` Ric Wheeler
2007-02-21 14:06                 ` Robert Hancock
2007-02-22 22:34                 ` Ric Wheeler
2007-02-23  0:04                   ` Robert Hancock
2007-02-21  8:44               ` Jens Axboe
2007-02-12  3:25 Robert Hancock
2007-02-12  8:31 ` Tejun Heo
2007-02-16 18:14   ` Jeff Garzik

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \

* 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).