Re: raid5-cache I/O path improvements V2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Shaohua Li <shli@xxxxxx> writes:

> On 9/11/15, 11:17 PM, "Christoph Hellwig" <hch@xxxxxx> wrote:
>
>>Hi Shaohua, hi Neil,
>>
>>this series contains a few updates to the raid5-cache feature.
>>
>>The first patch just ports it to the post-4.2 block layer.  As part of
>>that
>>I noticed that it currently doesn't handle I/O errors - fixes for that
>>will
>>follow.
>>
>>The second and third patch simplify the I/O unit state machine and reduce
>>latency and memory usage for the I/O units.  The remainder are just a
>>couple
>>of cleanups in this area that I stumbled upon.
>>
>>Changes since V1:
>> - only use REQ_FUA if supported natively by the log device
>
> Hi Christoph,
>
> I finally got some data with a Samsung SSD, which supports fua. Controller
> is ahci.
> Test is a simple fio with all full stripe write.
>
> libata.fua=0, throughput 247m/s
> libata.fua=1, throughput 74m/s

Eek!  That's a big price to pay!

>
> fua is significantly slower. I think we need a sysfs config to enable fua.

I don't want a sysfs config if we can possibly avoid it.

Christoph's code sets FUA on every block written to the log, both data
and metadata.  Is that really what we want?

I don't know much of the hardware details, but wouldn't setting FUA and
FLUSH on the last block written be just as effective and possibly faster
(by giving more flexibility to lower layers)??

NeilBrown

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux