Tag Info

New answers tagged

2

If you use either find ... -exec COMMAND {} + or find ... -print0 | xargs -0 COMMAND, xargs or find will be build a list of filename arguments no longer than each command’s defined buffer space (bounded by ARG_MAX). If the buffer space is exhausted, each command will pass the list of filename arguments to COMMAND and start creating a new list. That process ...


0

In addition to already suggested causes, it could be also following: a different disk is mounted "over" the existing folder which is full of data du will calculate the size spent of mounted disk and df will show really spent solution: (when possible) unmount all non-root disks and check the size with du -md 1 again. Fix situation by moving hidden folder to ...


1

du doesn't seem to accept files piped into it. I think what you're looking for is find /u02/archivelog -type f -mmin -1440 -exec du -ch {} + Using the + instead of the ; makes find build up {} as a list and executes once, instead of executing once for each match. You also need to use -type f, otherwise it'll match the directory itself, which is modified ...


1

Your use of {} \; limits the argument of ls to one element. If you are interested in the total of the archive logs you could use: find /u02/archivelog -mmin -1440 -type f -exec wc -c {} + | tail -1 To get the total number of bytes for the files under that directory. Where the {} + puts as many filenames on the commandline presented to wc as the system ...


0

Here is a bash/awk script for that: #!/bin/bash find . -type f -printf '%s\n' | awk ' function ceil(number) { if (number == int(number)) { return (number); } return int(number) + 1; } function ceilWithUnit(number, unit) { return ceil(number / unit) * unit; } BEGIN { blockSize = 32 * ...


1

I have no idea if there is a specific tool for that, but if I'd really want to figure it out, I'd make something like (in a script/program, of course) : count the files and multiplicate that by the cluster size. Of course, I would need to check their "range" (I mean see their size and check if it would take 4, 8, 32 or 64 KB cluster-wise). It's just an ...


3

/media/ is a stub where most modern distributions mount removable media when they are plugged in, e. g. USB hard drives, optical media, flash drives, etc. One of them you have mounted is identified as HDD2-200GB which is appearing as a 12.5GB filesystem, which is full. /mnt/ is another stub which is generally used for permanently mounted filesystems. ...


1

Additional blocks are allocated, as needed, to directories as files and sub-directories are added. Subsequent removal of these files and sub-directories do not result in disposal of the now empty/reusable allocation. Hence it is very common for the destination directory of a copy operation to be slightly smaller than its source. You can diff recursively ...


1

Different filesystems may have differing overhead while allocating space for files. Also how directory entries are stored may differ. You unfortunately don't tell what the different outputs are.


2

The information reported by your various tools are consistent. There is approximately 151Gb free on your disks, among which 141Gb for the /home directory and 11Gb for the rest of the system. What happens is that you program must install somewhere in /opt which is not under the same logical partition as /home when there is room but under the root partition ...


1

I would like to notice that it could also be a problem with mysql binary logs rather than with database files themself. Binlogs are placed in /var/log/mysql directory by default in many cases and they tend to consume few times more disk space than database files. It's because binlogs store all of the SQL data modifying queries (UPDATEs, INSERTs, etc.) to ...


4

MySQL data is stored in /var/lib. There is no more space in /var. MySQL does not start. Pretty simple actually. Have a look at /var/log and clean it up. I would recommend something like (delete all gz files in /var/log) : $ find /var/log -iname "*.gz" -delete Of course, you might wanna check what's being deleted first: $ find /var/log -iname "*.gz" ...


3

This is a useful command to find the largest files: du -ak /var | sort -nr | less Usage: du -ak summarizes the disk usage of all (-a) files in the /var partition and prints the size in kilobytes (-k). sort -nr Concatenates the list of files and sorts them into a reversed (-r) numerical (-n) order. less Will paginate the output so that you can see the ...


5

You should use /mnt in your case as it is on the second partition which has free space. You do not want to allow the root (/) partition to get full as you will run into trouble. For example, during the next system update your package manager may download many packages and crash while trying to install them, simply due to the lack of disk space. The ...


2

find ~ -type f -iname "*.pdf" -exec du -sh {} \; -exec runs programs being you mentioned via {} , Indeed you say to find command such as: du -sh *.pdf -type specifiy type of file , f mentioned to regular file. And ~ mentioned to path base path of search. -iname mentioned to Incasentisive search.


1

You have a 1TiB hard drive with only 10GiB or so used. While it would be possible to expand this 10GiB partition up to a TiB or any size in between, an alternative solution is to add another separate partition for your home directories. For example, add a new partition (/dev/sda6) and move the contents of your /home directory to it (this will need to be ...


1

The Standard of Practice is to enter into a Linux recovery environment. Any distribution Live-CD will enable you to access your computer in a manner appropriate to resize your hard drive partitions. Resizing partitions is based on the ability to work on your drive without having the drive actually mounted. $> fdisk -l Invoking the command above will ...



Top 50 recent answers are included