Tag Info

New answers tagged

0

You need more data; if you're having high %iowait you need to find out what is causing it. To do this you can use the following tools: iotop especially with -a. atop -d 1 sar is a great tool for historical logging; but you need to use a real-time tool for monitoring it. I made a pretty detailed post about doing this here: ...


0

The simplest is to change your current directory to / and execute : du -chs * | sort -h


0

try like this du -sh /home/dir 2> /dev/null | cut -f1


0

Note that if you want to know all {sub}folders size inside a directory, you can also use the -dor --max-depth option of du (which take an argument: the recursive limit) For instance : du -h /path/to/directory -d 1 Will show you something like 4.0K /path/to/directory/folder1 16M /path/to/directory/folder2 2.4G /path/to/directory/folder3 68M ...


2

How about that: find / -type d -name "softaculous_backups" -exec du -sm {} \; | sort -n For every found directory, du -sm is executed. After that all output is sorted numerically.


-1

$ df | tail +2 | sed s/%//g | awk '{ if($5 > 90) print "Alert "$0;}' df | tail +2 takes all the output after skipping the first 2 lines sed s/%//g strips percent signs awk ... prints "Alert ..."if the 5th field in the output is a number greater than 90


1

There's a bash script called 'lvm-usage' here (or google for it). Ensure that you receive text output from cron jobs (e.g. by mail), then set a regular cron job running lvm-usage.sh -q 80, you will be notified if any of your partitions are more than 80% full. (Despite the name, it doesn't require LVM).


2

TL;DR: because hard drives are in blocks of (mostly) 512 or some other power of 2 If you divide output of df -k (which is the default of GNU df version) by 1024 you actually get df -h.From reading Wikipedia as well as man page on my Ubuntu system for df, it appears that there is a historical reason for it, as Unix System V was consistently using 512 size ...


7

It is more precise to output the byte count rather than the human readable numbers. I use both, but when copying data or verifying file sizes, non-human readable is a must. Since one person's sensible default is another's constant annoyance, there's really no 'right' or 'wrong' answer. However, it is easy to force df to output human readable numbers: $ ...


5

I'm just guessing, but most Unix tools are built to work in pipelines. Viewed that way the number of bytes is probably the most useful, and thus a sensible default


1

In complement to @apaul, I emphasize that compressing files individually bzip2 *.log.* (replace bzip2 by gzip, xz, or what ever your favorite file zip is) may be important: This way you can still see (bzcat file.bz2), search (bzgrep file.bz2), edit (vi file.bz2) the compressed file and remove the older ones when necessary.


5

I figured out a tar solution by myself. It deletes single file after compressed it into the target file. The compressing speed is not quite fast, though. The command looks like: tar -zcvf my_log.tar.gz *.log --remove-files


9

gzip or bzip2 will compress the file and remove the non-compressed one automatically (this is their default behaviour). However, keep in mind that while the compressing process, both files will exists. If you want to compress log files (ie: files containing text), you may prefer bzip2, since it has a better ratio for text files. bzip2 -9 myfile # ...


0

The problem seemed to be that the OS on my machine was the same as the live image on the thumb drive I used to install it. When I called calamares it was attempting to reinstall the entire operating system again. The reason for the disk space issue was that calamares needed root privileges. My takeaway from this is that my distro (Maui) simply isn't quite ...



Top 50 recent answers are included