0

We have a postgres server with 6 SSDs in a raid10. backing up the postgres database with pg_dump works fine and causes almost 0 load to the disks or cpu. Tar'ing said pg_dump without any options other than -vcf seems to cause so much disk IO that queries start to timeout for a brief moment (5 minutes)

I'm trying to troubleshoot why this would be as pg_dump doesn't do this and tar should be similar to cat'ing the files together. Does writing to a luks encrypted disk require additional entropy? I thought it was entirely the key/passphrase?

2
  • No, they don't require additional entropy. The true randomness construction part happens only in the key generation, using the keys doesn't require anything only computing power (and writing the things requires disk IO). Check what is in the top during this 5 minutes, it is obviously extraordinary, but may have some specific reason. Also strace the tar.
    – peterh
    Aug 30, 2017 at 8:16
  • Thank you @peterh! I wasn't sure about the entropy but suspected it did not. Thanks for the confirmation!
    – Lookcrabs
    Sep 25, 2017 at 17:50

1 Answer 1

1

It seems that it has been fixed in kernels >= 4.0.2.

There is a deep analysis of this problem in Abysmal general dm-crypt (LUKS) write performance

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .