Alexander> I am in a process of evaluating dm-cache for our backup system. Why are you bothering to cache your backup destination? What filesystems are you using for your destinations? Alexander> Currently I have an issue when restart the backup Alexander> server. The server is booting for hours, because of IO Alexander> load. It seems is triggered a flush from SSD disk (that is Alexander> used for a cache device) to the raid controllers (they are Alexander> with slow SATA disks). I have 10 cached logical volumes in Alexander> writethrough mode, each with 2T of data over 2 raid Alexander> controllers. I use a single SSD disk for the cache. The Alexander> backup system is with lvm2-2.02.164-1 & kernel 4.4.30. How big is the SSD cache? Do you have any output from the bootup (syslog, dmesg, etc) you can share. Alexander> Do you have any ideas why such flush is triggered? In Alexander> writethrough cache mode we shouldn't have dirty blocks in Alexander> the cache. I wonder if it makes more sense to use 'lvcache' instead, since you can add/remove cache from LVs at will. With bcache, once you setup a volume with the cache, you're stuck with it. Also, did you mirror your SSD incase it fails? In my experience, using RAID6 on a bunch of SATA disks for backup is fine, you're writing large chunks of data in a few sets of files, so fragmentation and the Read-Modify-Write cycle is much less painful, since you tend to stream your writes to the storage, which is perfectly fine with SATA drives. Also, bcache skips sequential IO by default, which is what you want when doing backups... so I'm wondering what your thinking was here for using this? John -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel