Re: I/O Reordering: Cache -> Backing Device

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

 



On 2019/6/27 8:34 下午, Vojtech Pavlik wrote:
> On Thu, Jun 27, 2019 at 08:13:57PM +0800, Coly Li wrote:
> 
>>> Do you know how the nr_stripes, stripe_sectors_dirty and 
>>> full_dirty_stripes bitmaps work together to make a best-effort of writing 
>>> full stripes to the disk, and maybe you can explain under what 
>>> circumstances partial stripes would be written?
>> Hi Eric,
>>
>> I don't have satisfied answer to the above question. But if upper layers
>> don't issue I/Os with full stripe aligned, bcache cannot do anything
>> more than merging adjacent blocks. But for random I/Os, only a few part
>> of I/O requests can be merged, after writeback thread working for a
>> while, almost all writeback I/Os are small and not stripe-aligned, even
>> they are ordered by LBA address number.
>>
>> Thanks.
> 

Hi Vojtech,

> I wonder if it'd make sense for bcache on stripe-oriented backing
> devices to also try to readahead (or read-after) whole stripes from the
> backing device so that they're present in the cache and then write out a
> whole stripe even if the whole stripe isn't dirty.
> 

Let try it out. I assume if a write request hits a read-in cached full
stripe, the clean full-stripe-size block will be split into clean and
dirty part. But I don't fully understand the part of code so far, let me
try and maybe there is chance to improve (e.g mark the whole stripe as
dirty and write the whole stripe out).

> Working with whole stripes on a RAID6 makes a huge performance difference.
> 

Thanks for the hint!

-- 

Coly Li



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux ARM Kernel]     [Linux Filesystem Development]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux