I/O Reordering: Cache -> Backing Device

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

 



Hello,
I'm also interested in using bcache to facilitate stripe re-ass'y for the backing device.  I've done some experiments that dovetail with some of the traffic on this mailing list.  Specifically, in this message (https://www.spinics.net/lists/linux-bcache/msg07590.html), Eric suggested "...turning up /sys/block/bcache0/bcache/writeback_percent..." to increase the contiguous data in the cache.
My RAID-6 has a stripe size of 2.5MiB, and its bcache'ed with a few hundred GB of NVMe storage.  Here's my experiment:
* I made the cache a write back cache: echo writeback > /sys/block/bcache0/bcache/cache_mode
* I plugged the cache: echo 0 > /sys/block/bcache0/bcache/writeback_running
* I use a pathological I/O pattern, generated with 'fio': fio --bs=128K --direct=1 --rw=randwrite --ioengine=libaio --iodepth=1 --numjobs=1 --size=40G --name=/dev/bcache0.  I let it run to completion, at which point I believe I should have 40 GiB of sequential dirty data in cache, but not put there sequentially.  In essence, I should have ~16K complete stripes sitting in the cache, waiting to be written.
* I set stuff up to go like a bat: echo 0 > /sys/block/bcache0/bcache/writeback_percent; echo 0 > /sys/block/bcache0/bcache/writeback_delay; echo 2097152 > /sys/block/bcache0/bcache/writeback_rate
* And I unplugged the cache: echo 1 > /sys/block/bcache0/bcache/writeback_running
I then watched 'iostat', and saw that there were lots of read operations (statistically, after merging, about 1 read for every 7 writes) - more than I had expected... that's enough that I concluded it wasn't building full stripes.  It kinda looks like it's playing back a journal sorted in time then LBA, or something like that...
Any suggestions for improving (reducing) the ratio of reads to writes will be gratefully accepted!
Don Doerner
Technical Director, Advanced Projects
Quantum Corporation

Thanks,

-don-

The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through security software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.




[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