Tag Info

New answers tagged

1

du -ch /home/bzz/.cache* will give you the total size of all files which starts with .cache in /home/bzz/.


3

One cause for this is having files that have been deleted from disk, but are still open in memory. These files although deleted, still report as space taken up on the disk. You can check if you have any files in this state (and also which process is holding them open) with lsof. $ lsof | grep deleted open.pl 15220 steve 3r REG 8,1 70 56099817 ...


0

There are always a bit "missing"... First of all, the inode-tables, filename-lists in directories and stuff like that will take a bit of space. I remember old floppys - they were 1.44MB, but with a MS-DOS FAT filesystem, they could only hold 1.38MB. Second, Linux/Unix-filesystem usually reserve a few percent of the space for root. This way, if the users ...


1

I know I'm late to the party, but I believe this pure bash (or other shell which accept double star glob) solution could be much faster in some situations: shopt -s globstar # to enable ** glob in bash for dir in */; do a=( "$dir"/**/* ); printf "%s\t%s\n" "$dir:" "${#a[*]}"; done output: d1/: 302 d2/: 24 d3/: 640 ...


1

@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 ...


2

du works by scanning through the directory recursively, counting up the size of all the files & directories. Something like: start with the first directory given on the command line. stat the directory to determine its size, add that to the total read the first entry (file or subdirectory name) from the directory if it's a file, stat it and add it to ...


0

If you have rsync installed you can watch the copy progress like this rsync -vP big_directory new_location If you wanted to preserve permissions, timestamps, ownerships, etc. you would add the -a flag to rsync or the -p flag to cp. This answer sidesteps the use of du on the assumption that you actually wanted to watch the progress of the copy rather ...


1

df shows the free disk space on mounted partitions. If you give it a device name, it will try to find the corresponding mounted partition, and show you that; that's why df /dev/sda9 works on your system. But since /dev/sda1 isn't mounted, it finds the "closest" mounted filesystem, which is /dev, an 10MB RAM-based filesystem in your case. To find out the ...


2

This should do it. Where the first column (size) exceeds 10gb, output the second column (directory name) du -sk * | awk '$1 > 10485760 { print $2 }' Or as requested, to show in human readable form, as below. The regular expression ensures column 1 ends in a G (gigabytes) and the substr part strips the final letter from column 1 and looks to see if ...


3

du and df do not count the same things so it is rare from them to give the same results, though the differences are usually attributable to administrative overheads and areas reserved for special purposes. However, with 89% and 96% used you have much larger, and more urgent, problems to deal with.


3

Stripping is supposed to be safe, all it does is remove symbols from binaries, and they are only needed for debugging. So it should be safe to strip everything. In most Linux distributions (Mint included), binaries and libraries are stripped by default, and symbols are made available separately in debug packages. A binary or library which is not stripped ...


18

Most probably this is ext2, ext3 or ext4 file system which reserve a few percent of disk space (by default 5%) to be used only by specified users (usually root). If you create file system with mke2fs then -m option is what you are looking for: -m reserved-blocks-percentage Specify the percentage of the filesystem blocks reserved for the ...


0

What the “Blocks” value (the st_blocks field of a struct stat) measures exactly is not standardized. Traditionally, it counts the number of blocks that are used for filesystem content; this value multiplied by the block size is equal to the file size, rounded up to the nearest multiple of the block size. There's an exception: if the file is a sparse file, ...


0

Use tune2fs to determine inode size of the filesystem. $ df -k / Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 9156984 7509468 1159324 87% / $ tune2fs -l /dev/sda1|grep "^Inode size:" Inode size: 256 $



Top 50 recent answers are included