Hot answers tagged disk-space-utilization
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.
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 ...
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 ...
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
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.
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
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 ...
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: ...
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. ...
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 ...
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 ...
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
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 ...
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 ...
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.
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 ...
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 ...
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 ...
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.
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.
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 || ...
I believe that it's not your problem. To my mind it's some manager's problem. I don't think you need to be a hardass, but it sounds like somebody needs to be. The user's unfettered email storage is costing the company money. The user wouldn't be allowed to hoard trash in their office-- why should hoarding trash on the email server be any different? IT has ...
In Linux/Unix world file deletion does not necessarily immediately free the disk space, it merely unlinks the file from file system. If there are processes having file handles open to file being removed (as is common with syslog daemon, and in MySQL case, that mysql-slow.log), the space is not freed until the holding process is asked to reopen the file ...
This kind of problem is always really fun. My guess? You have files underneath one of your mountpoints. What does that mean? Well, du -sh will go by hand through all of the files that it can find. Let's say I have a directory, A. If I dump a bunch of files into A, and then mount, say, /dev/sdb on top of A, df -h will say I have a bunch of files that du ...
Try with the df -i which will show you how much free inodes you have. Basically sometimes you can run out of disk space to store metadata (data about data). That usually happens if you have a lot of small files.
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 ...
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, ...
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.
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.
Is this a one time thing, or is this information you want to be able to extract regularly? In case it is the later then one option is to apply quotas on your filesystem. Doing that the system continuously keeps track of the amount of data used by each user. That way the information is merely a query to the quota database away.
Only top voted, non community-wiki answers of a minimum length are eligible