Recently, I launched the cp command to create a backup of a big directory. So, I used a command like this: cp -rv big_directory new_locationBecause the files are big, it took a long time to execute this command, and I also wanted to look at the progress of the copy. So I also used the du command in another terminal, like this: du -sh new_location/*But this command also takes a long time to be executed. Specially if there are big files in this directory. Suppose that the cp command takes 10 minutes to be executed. If I launch the command du 1minute after having launched the cp command, and supposing that du takes 1 minute to be executed, I would like to know if I can trust the output of du? Does it give me a reliable output of the situation when du was launched (t=1min), or does it give me an output of the situation at the end of du execution time (t=2min)? Obviously the size of the directory new_location have changed between the start and the end of du command because of the copy. 
What is the output of du command during a long copy?
process;disk usage;cp
@derobert explained how du operates.He didn't mention that unless you have an absolutely huge number of small files / directories (so the metadata takes a huge amount of memory), then running du again right away usually produces a result much more quickly.One large file doesn't make du slow, but copying it is more likely to push directory caches out of memory.  (desktop responsiveness can be improved by setting vm.swappiness=10, and prioritizing metadata over data with vm.vfs_cache_pressure=60 sysctl settings (put them in /etc/sysctl.d/99-local.)When multiple processes are accessing the filesystem at the same time, every system call gets information that's a snapshot of the state when it was run.  For example, a process might check if a file existed, then try to open it, only to find out that it wasn't there anymore.  Because another process had renamed/removed it during that interval between checks.  (When this causes a problem / is the source of a bug, it's called a race condition.)If the order of du's directory traversal is the same as the order that cp chose, then du won't get to the still-being-modified directory until near the end of its run-time, and thus won't have missed much by the time it finishes.  OTOH, if du sums the directory where cp is putting new files first, and then takes another minute to sum the rest, the result will be stale.