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/afte
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 b
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 co
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 for
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.
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
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
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 -> bar
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
[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 d
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 re
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 no
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
[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
F
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
Hello, Robert.
Robert Hancock wrote:
[--snip--]
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 ra
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 con
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, a
Robert Hancock wrote:
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 this point I don't think
that's nee
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 Ma
20 matches
Mail list logo
