New answers tagged disk-usage
du actualy won't lie ;) It parses the dir(s) one gives it, counting only the first of all hardlinks pointing to the same inode it encounters. If you ask du what it sees in one directory only, it does not care that there are other hard links pointing to the same contents: $ du -h daily.0 && du -hc daily.1 29G /daily.0 29G /daily.1 Now give it ...
As @Gilles says, since du counts only the first of all hardlinks pointing to the same inode it encounters, you can give it directories in a row: $ du -hc --max-depth=0 dirA dirB 29G /hourly.1 1G /hourly.2 30G total I.e. any file in 'hourly.2' referencing an inode (aka "real" file) already referenced in 'hourly.1', will not be counted.
Others have mentioned du, but I would also like to mention Ncdu -- which is an ncurses version of du and provides interactivity: You can explore the directory hierarchy directly and see the sizes of subdirectories.
Just use the du command: du -sh * will give you the size of all the directories,files etc in current directory in human readable format. You can use the df command to know the free space in the disk: df -h .
The du command shows the disk usage of the file. The -h option shows results in human-readable form (e.g., 4k, 5M, 3G). du -h (file name)
du is your friend. If you just want do know the total size of a directory then jump into it and run: du -hs If you also would like to know which sub-folders spend how much disk space?! You could extend this command to: du -h --max-depth=1 | sort -hr which will give you the size of all sub-folders (level 1). The output will be sorted (largest folder on ...
du -sh is a good place to start. The options are (from man du): -s, --summarize display only a total for each argument -h, --human-readable print sizes in human readable format (e.g., 1K 234M 2G) To check more than one directory and see the total, use du -sch: -c, --total produce a grand total
fsck is telling you that 105570/171776 blocks are used, not KiB. As for df, your example shows the df results for the wrong filesystem. It shows the usage stats for /dev (an in-memory filesystem), not for the filesystem you thought you were measuring. That is because df takes as an argument the mountpoint of the mounted filesystem, not the block device. As ...
Ktorrent is using sparse files. Basically, a sparse file is a file with "holes" : no actual disk space is used for areas of the file which are "empty" (ie contains only zeroes). Your file thus appears to be of a certain size (in your case, the size of your Star Trek video), but is actually not using disk space for those areas that are not yet "filled" (in ...
du does a depth-first traversal of the given tree. By default, it shows the usage of every directory tree, showing the inclusive disk usage of each: $ du ~ 4 /home/bob/Videos 40 /home/bob/.cache/abrt 43284 /home/bob/.cache/mozilla/firefox 43288 /home/bob/.cache/mozilla 12 /home/bob/.cache/imsettings 48340 /home/bob/.cache 4 ...
You're summing the bytes, but the filesystem's block size is probably much larger than 1 byte. For an accurate count, you should be rounding each file's size up so that it's a multiple of the filesystem blocksize. With GNU coreutils installed, you can run stat --file-system $HOME to find the block size of the filesystem. On average, files will waste half a ...
Given that the filesystem was exported via NFS, there’s a fair chance that the discrepancy was due to deleted files... If files are deleted while open on NFS clients, lsof on the server won’t see them because there is no /proc/.../fd entry corresponding to them; but they will still occupy disk space as seen by df. Diagnosing this requires running lsof with ...
fuser -k -M -m /mnt/work should heel. Warning! it just literally kills processes accessing /mnt/work. Include -TERM to request termination. The culprit is deleted files that are held open, which du can't see but df could. For e.g. $ df -h . Filesystem Size Used Avail Use% Mounted on /dev/sda6 209M 66M 128M 35% /boot $ sudo du -sh . 64M ...
Top 50 recent answers are included