New answers tagged

1

If you see a mismatch between what df and dh report, you may have open files which are deleted but are still being written to. This takes up disk space (according to df), but is not reported anywhere (such as du) because the space doesn't belong to any existing file. If you experience this, you may need to restart some services (or the machine for a brute ...


1

All of the above examples will tell you the size of the data on disk (i.e. the amount of disk space a particular file is using, which is usually larger than the actual file size). There are some situations where these will not give you an accurate report, if the data is not actually stored on this particular disk and only inode references exist. In your ...


3

du uses stat(2) to find the number of blocks used by a file. If you run stat big you should see that the number of blocks matches the number given by du. You can force du to count bytes using the -b option; then its output matches ls's. In both cases it uses stat(2) (or rather, fstatat(2) at least in the version I have): $ strace du big|&grep big ...


2

As others have suggested you probably have the original files underneath /var/lib. If you don't (or can't) usefully boot the system into single user mode you can also access these with a "bind mount": mkdir -p -m700 /mnt/dsk mount --bind / /mnt/dsk cd /mnt/dsk/var/lib You are now in the "old" /var/lib that is hidden underneath the "new" /var/lib and you ...


0

What is the sum of / ( du -sh / )? The same as in df 99G? I thing files from /var/lib are still on /dev/xvda1 partition. They are "hidden" under mounted partition /dev/xvdf. You must boot live cd (e.g. sysrescure), then: mkdir /test mount /dev/xvda1 /test and try du -sh /test/var/ You should see your "hidden" space. You have to remove this files.


1

That's because 'migrating' your /var/lib to another partition does not automatically clean your original files. The trick would be to boot from another system (maybe a livecd), from there mount your /dev/xvda1 and delete the files in there. Please be careful, and make sure all the files are actually available in your new partition before trying this.


0

Had some time to look into this. Perhaps could you share your Solaris version? I have tried this on a Solaris 11.3 system: # pkg list entire NAME (PUBLISHER) VERSION IFO entire 0.5.11-0.175.3.1.0.5.0 i-- # zfs set groupquota@staff=2G ...


0

PackageKit is used by GNOME. If you use Yum or DNF on the CLI then don't need these. You can remove the .rpm files in /var/cache/PackageKit/metadata/updates/packages and set PackageKit to not store them any longer. There is a setting in the file /etc/PackageKit/PackageKit.conf # Keep the packages after they have been downloaded #KeepCache=false As root, ...


1

It is not simply "rounding". dfc (and di) print the value rounded to the nearest representation in digits, while df rounds up. The question does not specify a version of coreutils; I'm answering based on version 8.13 (in Debian 7), though I see the same result with 8.25. Start with the -h option in df.c: case 'h': human_output_opts = ...


0

With GNU sort specify -T dir (or --temporary-directory=dir) where dir is a writable directory on a filesystem with enough space, such as /home/$USER/mytemp for the layout you posted.


0

Your problem is that the /tmp is only 1Mb, while the file to be sorted is 4Gb. I don't know perfectly how sort works but it is surely using /tmp (as stated in the error) and the 1Mb is not enough. You should create another partition and mount that in the /tmp, or if you can not do this, create a virtual disk of 10-20Gb (or bigger) with fallocate or dd in ...


3

The "blocks" that stat() reports are 512 byte units. The normal block size used by ext4 is 4kb, or 8 of these "blocks". That means that the space used by a file on ext4 must be an integer multiple of 8 "blocks", and so the smallest size used by any file less than or equal to 4096 bytes in size is 8 512 byte blocks.


-1

The ext4 filesystem speculates the size of a file when it is created. Quoting below from this link: When a file is first created, the block allocator speculatively allocates 8KiB of disk space to the file on the assumption that the space will get written soon. When the file is closed, the unused speculative allocations are of course freed, but if the ...


0

Two suggested answers are specific to Linux. Here's a suggestion, sticking to POSIX: #!/bin/sh find "$@" -type f |\ xargs du -s |\ awk 'BEGIN {total = 0;} { total += $1; } END { print total; }' Alternatively, you could attempt to work around spaces in pathnames (still POSIX): #!/bin/sh find "$@" -type f -exec du -s {} + |\ awk 'BEGIN {total = 0;} { ...


1

If you have GNU find, you can make it print the file sizes. find /source ! -type d -printf '%P %s\n' Sort the output to get deterministic output. If the filenames contain newlines, it's possible to get the same sorted output for different arrangements, but that's not going to happen unless deliberately engineered. comm -3 <(find /source ! -type d ...


3

Simply feed it a list of everything you DO want counted using --files0-from find -type f -print0 | du --files0-from=-


-1

I believe what you are looking for is --max-depth. So for example. If you wanted to calculate the disk usage of a directory without all of its subdirectories this is how it would be done. du [directory name] --max-depth=1 If you wanted to find the size of its subdirectories too just increase the depth. I found a link that gives a lot of information on ...


1

Although you could resize a filesystem with command line tools, I recommend to use GParted. You should be able to install it with your package manager, or you download the CD image, mount it to the VM and reboot to start it.



Top 50 recent answers are included