LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Robert Hancock <hancockr@shaw.ca>
To: ric@emc.com
Cc: Tejun Heo <htejun@gmail.com>, Jens Axboe <jens.axboe@oracle.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-ide@vger.kernel.org, edmudama@gmail.com,
	Nicolas.Mailhot@LaPoste.net, Jeff Garzik <jeff@garzik.org>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>, Mark Lord <mlord@pobox.com>,
	Dongjun Shin <d.j.shin@samsung.com>,
	Hannes Reinecke <hare@suse.de>
Subject: Re: libata FUA revisited
Date: Thu, 22 Feb 2007 18:04:05 -0600	[thread overview]
Message-ID: <45DE2F75.2030700@shaw.ca> (raw)
In-Reply-To: <45DE1A7C.1030500@emc.com>

Ric Wheeler wrote:
>>> 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
> 
> A couple of issues with this would be in how to support our current 
> semantics of fsync().  Today, the flush behavior of the barrier/fsync 
> combination means that applications can have a hard promise of data on 
> platter for any file after a successful fsync command.
> 
> If I understand correctly, to get a similar semantic from a pure FUA 
> implementation would require us to tag all file IO as FUA.
> 
> I suspect that this would actually be less efficient since it would not 
> allow the drives to reorder IO's up to the point that we actually care 
> (fsync time).

I think for the fsync case a cache flush would likely still be needed, 
unless the app was only writing small amounts of data in between the 
syncs (it may be complicated to figure out when to do that, though).

> The other big user of barriers is the internal transaction of journaled 
> file systems.  It would seem that we would need to tag each write from 
> the journal with a FUA IO as well.  Again, we might actually go more 
> slowly in some cases as you mention below.
> 
> The limited queue depth of NCQ would seem to make it much harder to have 
> a win in this case...

I think the journal write case is less problematic as there are likely 
to be much fewer/smaller requests involved which would be more likely to 
fit inside the queue..

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/



  reply	other threads:[~2007-02-23  0:04 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.S80SRyQbD/hm4SxliPUKU88BaCo@ifi.uio.no>
2007-02-12  5:47 ` Robert Hancock
     [not found] ` <fa.Q/csgyCHkAsD84yi+bN78H1WNNM@ifi.uio.no>
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
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 [this message]
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:
  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=45DE2F75.2030700@shaw.ca \
    --to=hancockr@shaw.ca \
    --cc=Nicolas.Mailhot@LaPoste.net \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=d.j.shin@samsung.com \
    --cc=edmudama@gmail.com \
    --cc=hare@suse.de \
    --cc=htejun@gmail.com \
    --cc=jeff@garzik.org \
    --cc=jens.axboe@oracle.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mlord@pobox.com \
    --cc=ric@emc.com \
    --subject='Re: libata FUA revisited' \
    /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

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