Re: dm-cache performance behaviour

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

 



2016-04-07 4:24 GMT+03:00 Eric Wheeler <bcache@xxxxxxxxxxxxxxxxxx>:
> You might consider tweaking {read,write}_promote_adjustment with
>         dmsetup message /dev/mapper/foo 0 read_promote_adjustment X
> or at initial table creation time to shorten cache heat time.
>
> You could use this with LVM tools:
>   lvchange --cachesettings 'read_promote_adjustment = 1' vg/cachedvol
>
> See descriptions here:
>
> https://www.kernel.org/doc/Documentation/device-mapper/cache-policies.txt
>
> When we used dm-cache I would set the promote values to 1 (or 0?) to heat
> up the cache and then increment them after the cache filled.
>
>> bcache:
>> - writeback cache mode
>> - LRU cache policy
>
> bcache defaults to 512k bucket size iirc, you'll want to specify -b 256k
> on your make-bcache call for an apples-to-apples comparison.  FWIW, I like
> the 64k size best for our workload.
>
> --
> Eric Wheeler


Does somebody can test bcache vs dm-writeboost vs dm-cache on latest
stable kernels ?


-- 
Vasiliy Tolstov,
e-mail: v.tolstov@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux