Tag Info

New answers tagged


My answer is inline with others, but I can't comment yet so I get to start new: Most files in /Applications are compressed and when you copy it that is lost. When compression is used in HFS+ the files data is stored in the Resource Fork OR an extended attribute if it's small enough ( less than 4k). If it's in a resource fork du (at least on Yosemite) will ...


These both work for me: du -h | perl -ne '$n=()=$_=~m#/#g; print unless $n > 2' du -h | perl -ne 'print unless ($n=()=$_=~m#/#g) > 2 '


Ok, I know I'm a Windows user, not a linux user, but I had a similar issue a while ago when trying to copy files to a 16Gig data stick, to transfer to and from an old laptop. As it turned out, most of the file system formats for removable devices (ext2, fat32 etc), don't support copying files if the file is greater than 3.2Gigs in size, because of some ...


Your 8GB stick has approximately 7.5 GiB and even with some file system overhead should be able to store the 5.4GiB file. You use tune2fs to check the file sytem status and properties: tune2fs -l /dev/<device> By default 5% of the space is reserved for the root user. Your output lists 97894 blocks, which corresponds to approximately 385MiB and ...


Try this: find / -user <someuser> -type f -printf '%s\t%p\n' | sort -rn | head -1 The above uses GNU find(1) and assumes no filenames have embedded newlines. It also has to be run as root (otherwise it wouldn't be able to read all directories).


You can use the find command for this. To search your entire filesystem for files owned by user exampleuser use: $ sudo find / -user exampleuser If you want search for large files add the -size option: $ sudo find / -user exampleuser -size +10000k This: +10000k will find files greater than 10,000 kilobytes in size.


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


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


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


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


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.


$ 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


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


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


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: $ ...


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

Top 50 recent answers are included