barrier code is broken in many ways:
Currently only ->dio_submit() handles PLOOP_REQ_FORCE_{FLUSH,FUA} correctly.
But request also can goes though ->dio_submit_alloc()->dio_submit_pad and
write_page (for indexes)
So in case of grow_dev we have following sequance:
E_RELOC_DATA_READ:
-
Dima,
I agree that the ploop barrier code is broken in many ways, but I don't
think the patch actually fixes it. I hope you would agree that
completion of REQ_FUA guarantees only landing that particular bio to the
disk; it says nothing about flushing previously submitted (and
completed) bio-s
Maxim Patlasov writes:
> Dima,
>
> I agree that the ploop barrier code is broken in many ways, but I don't
> think the patch actually fixes it. I hope you would agree that
> completion of REQ_FUA guarantees only landing that particular bio to the
> disk; it says nothing about flushing previous
Dmitry Monakhov writes:
> Maxim Patlasov writes:
>
>> Dima,
>>
>> I agree that the ploop barrier code is broken in many ways, but I don't
>> think the patch actually fixes it. I hope you would agree that
>> completion of REQ_FUA guarantees only landing that particular bio to the
>> disk; it s
On 06/16/2016 09:30 AM, Dmitry Monakhov wrote:
Dmitry Monakhov writes:
Maxim Patlasov writes:
Dima,
I agree that the ploop barrier code is broken in many ways, but I don't
think the patch actually fixes it. I hope you would agree that
completion of REQ_FUA guarantees only landing that part
Maxim Patlasov writes:
> On 06/16/2016 09:30 AM, Dmitry Monakhov wrote:
>> Dmitry Monakhov writes:
>>
>>> Maxim Patlasov writes:
>>>
Dima,
I agree that the ploop barrier code is broken in many ways, but I don't
think the patch actually fixes it. I hope you would agree that
>
barrier code is broken in many ways:
Currently only ->dio_submit() handles PLOOP_REQ_FORCE_{FLUSH,FUA} correctly.
But request also can goes though ->dio_submit_alloc()->dio_submit_pad and
write_page (for indexes)
So in case of grow_dev we have following sequance:
E_RELOC_DATA_READ:
-
Dima,
On 06/19/2016 06:06 AM, Dmitry Monakhov wrote:
Maxim Patlasov writes:
On 06/16/2016 09:30 AM, Dmitry Monakhov wrote:
Dmitry Monakhov writes:
Maxim Patlasov writes:
Dima,
I agree that the ploop barrier code is broken in many ways, but I don't
think the patch actually fixes it. I
barrier code is broken in many ways:
Currently only ->dio_submit() handles PLOOP_REQ_FORCE_{FLUSH,FUA} correctly.
But request also can goes though ->dio_submit_alloc()->dio_submit_pad and
write_page (for indexes)
So in case of grow_dev we have following sequance:
E_RELOC_DATA_READ:
-
Dima,
I agree with general approach of this patch, but there are some
(easy-to-fix) issues. See, please, inline comments below...
On 06/20/2016 11:58 AM, Dmitry Monakhov wrote:
barrier code is broken in many ways:
Currently only ->dio_submit() handles PLOOP_REQ_FORCE_{FLUSH,FUA} correctly.
Bu
Maxim Patlasov writes:
> Dima,
>
> I agree with general approach of this patch, but there are some
> (easy-to-fix) issues. See, please, inline comments below...
>
> On 06/20/2016 11:58 AM, Dmitry Monakhov wrote:
>> barrier code is broken in many ways:
>> Currently only ->dio_submit() handles PLO
On 06/21/2016 12:25 AM, Dmitry Monakhov wrote:
Maxim Patlasov writes:
Dima,
I agree with general approach of this patch, but there are some
(easy-to-fix) issues. See, please, inline comments below...
On 06/20/2016 11:58 AM, Dmitry Monakhov wrote:
barrier code is broken in many ways:
Current
Dima,
After more thinking I realized that the whole idea of
PLOOP_REQ_DELAYED_FLUSH might be bogus: it is possible that we simply do
not have many enough incoming FUA-s to make delaying lucrative. This
patch actually mixes three things: 1) fix barriers for RELOC_A|S
requests, 2) fix barriers
Dima,
I'm uneasy that we still have handling RELOC_A|S broken. It seems we
have full agreement that for such requests we can do unconditional
FLUSH|FUA when we call write_page from ploop_index_update() and
map_wb_complete(). And your idea to implement it by passing FLUSH|FUA
for io_direct and
14 matches
Mail list logo
