All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Hancock <hancockr@shaw.ca>
To: Tejun Heo <htejun@gmail.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	linux-ide@vger.kernel.org, edmudama@gmail.com,
	Nicolas.Mailhot@LaPoste.net
Subject: Re: libata FUA revisited
Date: Tue, 13 Feb 2007 18:07:41 -0600	[thread overview]
Message-ID: <45D252CD.5010303@shaw.ca> (raw)
In-Reply-To: <45D1D72D.9020509@gmail.com>

Tejun Heo wrote:
>> On the NCQ side, I think it's pretty safe to assume that all 
>> controllers will handle it. Obviously I've verified it with sata_nv 
>> (at least that it doesn't blow up obviously), and the other two NCQ 
>> drivers we have, ahci and sata_sil24 just feed raw FIS data into the 
>> controller so there should be no issue with not supporting it.
> 
> FWIW, ICH6/7/8 ahci's clear PMP field when transmitting FIS.  The reason 
> why I'm hesitant is because there is no way to tell whether the FUA bit 
> got honored or ignored.  With extra opcode, it's okay because barrier 
> explicitly fails but if NCQ FUA is not supported, it will succeed 
> silently as normal write.  Everything will be okay generally but the 
> barrier is done incorrectly and on a really bad day it will lead to 
> journal corruption.

Well, we should be able to determine that experimentally (at least on 
specific controllers) with a little test program that just writes little 
bits of data and fsyncs repeatedly (assuming that does in fact trigger 
FUAs currently..) If it runs faster than the drive could possibly be 
rewriting the physical disk then obviously the FUA bit is not getting 
through and/or not respected and we can blacklist FUA on that controller.

Also, the FUA bit in the NCQ commands is in the device register, so it's 
not like the PMP fields where it's not used for anything else and so the 
controller messing with it wouldn't be otherwise noticed..

> 
> So, actually, I was thinking about *always* using the non-NCQ FUA 
> opcode.  As currently implemented, FUA request is always issued by 
> itself, so NCQ doesn't make any difference there.  So, I think it would 
> be better to turn on FUA on driver-by-driver basis whether the 
> controller supports NCQ or not.

Unfortunately not all drives that support NCQ support the non-NCQ FUA 
commands (my Seagates are like this).

There's definitely a potential advantage to FUA with NCQ - if you have 
non-synchronous accesses going on concurrently with synchronous ones, if 
you have to use non-NCQ FUA or flush cache commands, you have to wait 
for all the IOs of both types to drain out before you can issue the 
flush (since those can't be overlapped with the NCQ read/writes). And if 
you can only use flush cache, then you're forcing all the writes to be 
flushed including the non-synchronous ones you didn't care about. 
Whether or not the block layer currently exploits this I don't know, but 
it definitely could.

> Well, I might be being too paranoid but silent FUA failure would be 
> really hard to diagnose if that ever happens (and I'm fairly certain 
> that it will on some firmwares).

Well, there are also probably drives that ignore flush cache commands or 
  fail to do other things that they should. There's only so far we can 
go in coping if the firmware authors are being retarded. If any drive is 
broken like that we should likely just blacklist NCQ on it entirely as 
obviously little thought or testing went into the implementation..

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



  reply	other threads:[~2007-02-14  0:14 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 [this message]
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
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=45D252CD.5010303@shaw.ca \
    --to=hancockr@shaw.ca \
    --cc=Nicolas.Mailhot@LaPoste.net \
    --cc=edmudama@gmail.com \
    --cc=htejun@gmail.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 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.