Filling a large HDD with /dev/urandom prior to encryption can be extremely slow (even with netcat, multiple instances in parallel, etc) and for this reason I'm sure a lot of users skip this advice even if it is recommended practice and unsafe to omit.
My question is: Assume a user has omitted this step of filling the disk with /dev/urandom, or only done it partially. Are there any steps that can be taken after the HDD has been encrypted to make it harder to perform cryptanalysis on the disk?
I'm assuming the best case scenario for the attacker would be if the user filled the entire disk with /dev/zero and then encrypted it? Would it then help if the user filled the entire disk (after having encrypted it) by writing /dev/zero to some arbitrary file in the file system, then deleted the file to recover the 'used' space? Wouldn't this remove any stray null bytes on the device and replace everything with just encrypted data?
So in the more realistic case, would it help to fill the disk with data after it has been encrypted? If not, why not? Imagine the disk has actually been filled to the maximum capacity after it has encrypted, what value does then the prior filling with random data before encryption hold? All that /dev/urandom data has been overwritten anyway, so what value does that operation hold at that stage?
If needed assume the system is: x86-64 GNU/Linux with LUKS, 256 bit AES, mechanical HDD (does this change with SSD? Please include why, as that would be interesting).
Attack scenario: The HDD is stolen and obtained removed from the computer by the attacker, preventing attacks such as evil maid and cold boot attacks.