Jens Axboe wrote:
On Wed, Feb 21 2007, Tejun Heo wrote:
[cc'ing Ric, Hannes and Dongjun, Hello. Feel free to drag other people in.]
Robert Hancock wrote:
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
Tejun Heo wrote:
[cc'ing Ric, Hannes and Dongjun, Hello. Feel free to drag other people in.]
Robert Hancock wrote:
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
Tejun Heo wrote:
Jens Axboe wrote:
On Wed, Feb 21 2007, Tejun Heo wrote:
[cc'ing Ric, Hannes and Dongjun, Hello. Feel free to drag other people in.]
Robert Hancock wrote:
Jens Axboe wrote:
But we can't really change that, since you need the cache flushed before
issuing the FUA write. I've
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
[cc'ing Ric, Hannes and Dongjun, Hello. Feel free to drag other people in.]
Robert Hancock wrote:
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:
On Wed, Feb 21 2007, Tejun Heo wrote:
[cc'ing Ric, Hannes and Dongjun, Hello. Feel free to drag other people in.]
Robert Hancock wrote:
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
On Mon, Feb 19 2007, Robert Hancock wrote:
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:
3. w/FUA+ORDERED
normal operation - barrier issued -
Jens Axboe wrote:
On Wed, Feb 21 2007, Tejun Heo wrote:
[cc'ing Ric, Hannes and Dongjun, Hello. Feel free to drag other people in.]
Robert Hancock wrote:
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
On Wed, Feb 21 2007, Tejun Heo wrote:
Jens Axboe wrote:
On Wed, Feb 21 2007, Tejun Heo wrote:
[cc'ing Ric, Hannes and Dongjun, Hello. Feel free to drag other people
in.]
Robert Hancock wrote:
Jens Axboe wrote:
But we can't really change that, since you need the cache flushed
Tejun Heo wrote:
Aside from the issue above, as I mentioned elsewhere, lots of NCQ drives
don't support non-NCQ FUA writes..
To me, using the NCQ FUA bit on such drives doesn't seem to be a good
idea. Maybe I'm just too chicken but it's not like we can gain a lot
from doing FUA at this point.
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:
3. w/FUA+ORDERED
normal operation - barrier issued - write barrier FUA+ORDERED
- normal operation
Tejun Heo wrote:
Hello,
Robert Hancock wrote:
[--correct summary snipped--]
Given the above, what I'm proposing to do is:
-Remove the blacklisting of Maxtor BANC1G10 firmware for FUA. If we
need to FUA-blacklist any drives this should likely be added to the
existing horkage mechanism we now
On Tue, Feb 13 2007, Tejun Heo wrote:
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
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
[cc'ing Jeff, Alan, Mark and Jens. Hi!]
Hello, Robert.
Robert Hancock wrote:
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
Hello,
Robert Hancock wrote:
[--correct summary snipped--]
Given the above, what I'm proposing to do is:
-Remove the blacklisting of Maxtor BANC1G10 firmware for FUA. If we need
to FUA-blacklist any drives this should likely be added to the existing
horkage mechanism we now have. However, at
Tejun Heo wrote:
-Add a new port flag ATA_FLAG_NO_FUA to indicate that a controller
can't handle FUA commands, and add that flag to sata_sil. Force FUA
off on any drive connected to a controller with this bit set.
There was some talk that sata_mv might have this problem, but I
believe the
I've been looking at some list archives from about a year ago when there
was a big hoohah about FUA in libata. To summarize what I've gotten from
that discussion:
Nicolas Mailhot ran into a problem with the first kernels that supported
libata FUA, using a Silicon Image 3114 controller and a
18 matches
Mail list logo
