The output of du is based on filesystem-level statistics, whereas ncdu (and a regular du) generate their results by scanning through directories, reading the sizes of individual files, and summarizing that.
If the du-style commands are run as a non-root user, they won't necessary have full access to all directories, and so may not be able to see everything.
You can avoid the xargs:
du -sc */
Using xargs would only be useful if you have several thousands directories to avoid a "command line too long" error (but then would would not have a full total, only partial totals for each invocation of du by xarg).
Trick for other commands, to avoid the mis-parsing file names by xargs, have them separated by nulls ...
You probably have an app/process that has that file open. When you delete a file that is held open by an app the OS still sees the file size in df as the file is still open in memory.
Here is some documentation I wrote for a co worker that should get you what you need.
Truncate large open files
You have deleted files to free space but space not free ...
Here is one partial solution. It only stops files from filling the disk space not reserve space for critical user GUI functions.
The outline is to use iotop output to identify high IO usage or a threshold of cumulative IO write, say 50 or 100mbs, to send a warning, and then to stop the process once it has written 90% of the disk space. And send a warning ...
The correct way to solve this problem is to move the docker data directory to another location where there is sufficient space. In my case this was my home partition.
To do that I had to create a daemon.json file in /etc/docker and add the following lines to it:
Then restart the docker service, if you are ...