poor random write performance about dmdedup3.19 HOT 3 CLOSED

from dmdedup3.19.

For deduplication, there are extra components in the write path when compared to normal writes:

1. calculate the checksum for the block
2. check whether the checksum exists in the metadata
3. Decide to share / write new block. Since your workflow has only 30% deduplication - we are going to end up writing both metadata and data device for the remaining 70 % writes

Provided the fact that you are using the same physical device for storing both meta-data and data, the high latency is expected.

We suggest using different SSDs for storing metadata device(to verify if it significantly affects the performance).

It would also be helpful if you can provide the stats for data with different duplicate %. (For example 90 , 70, 50, 0).

Also please use the new kernel version. You can find the source here
https://github.com/dmdedup/dmdedup4.8

Thanks.

from dmdedup3.19.

tested on dmdedup4.8 as suggested, issue still persists, please see dmdedup/dmdedup4.8#3

from dmdedup3.19.