Hot answers tagged

75

Deleting the filename doesn't actually delete the file. Some other process is holding the file open, causing it to not be deleted; restart or kill that process to release the file. Use lsof +L1 to find out which process is using a deleted (unlinked) file.


63

stop the VM run qemu-img resize vmdisk.img +10G to increase image size by 10Gb start the VM, resize the partitions and LVM structure within it normally


55

Check for files on located under mount points. Frequently if you mount a directory (say a sambafs) onto a filesystem that already had a file or directories under it, you lose the ability to see those files, but they're still consuming space on the underlying disk. I've had file copies while in single user mode dump files into directories that I couldn't ...


54

This is a common interview question and a situation that comes up in a variety of production environments. The file's directory entries have been deleted, but the logging process is still running. The space won't be reclaimed by the operating system until all file handles have been closed (e.g., the process has been killed) and all directory entries ...


25

One simple way to get Windows Server 2008 to send low disk space e-mail alerts is to use Task Scheduler and the System Log. If the free space falls below the percentage specified in HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\DiskSpaceThreshold, an event is recorded in the System Log that can trigger a task to send an e-mail message. ...


25

Try: $ lsof +L1 This will find files that have a link count less than 1 (files removed but still beeing written to). For those times when du and df don't match up.


25

Just stumbled on this page when trying to track down an issue on a local server. In my case the df -h and du -sh mismatched by about 50% of the hard disk size. This was caused by apache (httpd) keeping large log files in memory which had been deleted from disk. This was tracked down by running lsof | grep "/var" | grep deleted where /var was the partition ...


23

You may want to try the ncdu utility found at: http://dev.yorhel.nl/ncdu It will quicky sum the contents of a filesystem or directory tree and print the results, sorted by size. It's a really nice way to drill-down interactively and see what's consuming drive space. Additionally, it can be faster than some du combinations. The typical output looks like: ...


22

Our solution was a pit painful. One of our partner organizations (k12 education) was hit by discovery request in a lawsuit (FOIA). The costs to sort through the tons of email and redact the secret bits was huge (~$100k) because of how much email was saved that may have match the request. Our lawyers suggested, and our Superintendent put into place a ...


21

Surely there are more elaborate ways, but the one I remember is du --max-depth=1 -h / Now take the directory that uses up most space (du --max-depth=1 -h /yourdir) and go deeper until you find your culprit. If want your output sorted by size and don't care for the human-readable format, you could also do du --max-depth=1 /your_dir | sort -n


20

Proper design I assume you are unable to simply extend the filesystem in question (using lvextend && ext2online), because you do not use LVM or use wrong filesystem type. Your approach What you've proposed might work if you signal the daemons with SIGHUP (kill -1 pid). Obviously you would need to later on "mount -o bind / /somewhere" and clean up ...


16

You generally want to leave about 10% free to avoid fragmentation, but there is a catch. Linux, by default, will reserve 5% of the disk for the root user. When you use 'df', the output doesn't include that 5% if you run it as a non-root user. Just something to keep in mind when doing your calulations. Incidentally, you can change the root reserve by ...


16

See what df -i says. It could be that you are out of inodes, which might happen if there are a large number of small files in that filesystem, which uses up all the available inodes without consuming all the available space.


16

There isn't much to do here. Your current check is syntactically correct, but may not be practical. Why do you care if space utilization is greater than 10%??!? A typical disk check stanza would look like: check device var with path /var if SPACE usage > 80% then alert That basically will send an email if the drive is more than 80% full. Monit ...


15

You can see the 10 largest directories with: du -cks *|sort -rn|head This will recursively add up the sizes of everything in each directory - but you would have to manually execute it at each level to get a breakdown of what's in each


15

The most error-proof solution is to make the mount point unwritable. This would be your solution #3. However there is one additional step you should perform. chattr +i /mnt/backups. This is because even with no permissions, root would still be able to write to the directory. With chattr +i (sets immutable flag) not even root can write to it. Once the mount ...


14

NCurses Disk Usage (ncdu) is good for this. See http://dev.yorhel.nl/ncdu for details. It's available as a package for most popular distributions and lets you browse and find out where your disk space is used. It uses text characters to display a bar-chart of directory usage so you get a semi-graphical interface, in a text only environment.


14

There's still another link to the file (either hard link or open file handle). Deleting a file only deletes the directory entry; the file data and inode hang around until the last reference to it has been removed. It's somewhat common practice for a service to create a temporary file and immediately delete it while keeping the file open. This creates a file ...


14

Yes you can delete them and I recommend it as well. The docs for Puppet dashboard aren't very opinionated on the ongoing maintenance of the dashboard, but it does need maintenance. I recommend a cron that delete reports in the database after a few days, a second one to remove any orphaned records, and a third to delete processed reports. Mine looks like ...


13

Don't expect this to run quickly... cd to a directory where you suspect there might be a subdirectory with lots of inodes. If this script takes a huge amount of time, you've likely found where in the filesystem to look. /var is a good start... Otherwise, if you change to the top directory in that filesystem and run this and wait for it to finish, you'll ...


13

Here's my standard "find what's eating the space" regime: du -hx --max-depth=1 / -- look for what's eating the space. Examine the largest subdirectory (say du -hx --max-depth=1 /var) until you find some space hogs. Logs (in /var/log) are common culprits (which you should deal with using logrotate), as are the cruft that yum likes to keep around ...


13

It sounds like the file is still open by some process. You'll need to restart that service for the disk space to be freed.


13

I use this one a lot. du -kscx * It can take a while to run, but it'll tell you where the disk space is being used.


13

These serverfault questions are similar but more specific, KVM online disk resize? & Centos Xen resizing DomU partition and volume group. The 1st asks the question of how to increase a KVM guest while it's online, while the 2nd is XEN specific using LVM. I'm asking how to accomplish this while the KVM is offline. NOTE: This link was useful for METHOD ...


13

Use the mysqldump utility to direct the file wherever you like: mysqldump -A -u[username] -p[password] > /path/to/dest/backupname.sql If you need to, you can pipe the output through gzip: mysqldump -A -u[username] -p[password] | gzip -c > /path/to/dest/backupname.gz Further, you can send the output from gzip to another server via ssh: mysqldump ...


12

It's entirely possible that you have a very large deleted file (or lots of little ones) that a process still has an open file handle on. The way to find them is to run # lsof | grep "deleted" If you see lots of lines that end with "(deleted)" then you can find the process Id that has them open and restart it. Once that happens, your disk space should ...


12

as Ignacio mentions, deleting the file won't free the space until you delete the processes that have open handles against that file. Nevertheless, you can reclaim the space without killing the processes. All you need to do is to remove the file descriptors. First execute lsof | grep deleted to identify the process holding the file [hudson@opsynxvm0055 ...


12

Number 5 - Put a test in your backup script to ensure that the directory is mounted before continuing. The script should fail if the mount is not available or present. Or you can just make sure things are mounted prior to running the backup. Try the mountpoint command, which checks if a specified directory is a mountpoint: mountpoint -q /mnt/backups || ...


12

The file you deleted will still be open and Apache will be writing to it. You will need to restart Apache to allow it to create a new file. A graceful restart should do the trick apachctl -k graceful or apache2ctl -k graceful or whatever your distro uses.


11

MySQL use of DiskSpace is quite predictable. The information_schema can quickly give away how much space is used by both storage engines. However, it is far better to configure InnoDB with innodb_file_per_table. That way, you can micromanage the diskspace of individual InnoDB tables. If you do not have innodb_file_per_table, the ibdata1 will grow and NEVER, ...



Only top voted, non community-wiki answers of a minimum length are eligible