Space Issue

UNIX for Advanced & Expert Users
1

Hey Experts,

I'm facing an issue related to space in the unix system. I have a mount point where 9.4 T is allocated. The entire mount point is filled and I can trace only for 6.7T but I could not located the rest of the space around 2T. I tried every single command to locate the file starting with find,du,df etc but no luck. Requesting you all to please help me find that hidden space.

Filesystem size used avail capacity Mounted on
/dev/vx/dsk/edwqadg/edw_qa
9.4T 9.3T 60G 100% /edw_qa

2

They may be in deleted files. files which are deleted while still in use, will remain on disk until the files are closed. If someone naively deletes files to free up space, this may cause a problem that only restarting the process hogging them, or rebooting the machine, can resolve.

1 Like
3

Deleted files on NFS if still open are renamed in place to a funny .nfs* name, and other open deleted files used to go to /mount-point/lost+found/ You might be able to see them using lsof, and kill the processes that are holding them. On some systems the deleted files are still linked in /proc/$$/ or the like. If the files are still alive somewhere, you can run fuser on them to find using procs. To see where visible space is, I do something like this:

sort -nrm <( du -dk /mount-point | sort -nr | sed 's/$/\//' ) <( find /mount-point -mount -type f | xargs -r du -k | sort -nr )|pg

However, it misses big directories. du forgets them. Just for big directories, use something like this (reports in pages):

find /mount-point -mount -type d | xargs -r ls -sd | sort -nr | pg

There is no utility to shrink huge directories, but something like this is good if there is no white space in entry names and the directory is quiescent:

mkdir /huge_path'X'
ls -A /huge_path | ( cd /huge_path ; mv `cat` /huge_path'X' )
rmdir /huge_path
mv /huge_path'X' /huge_path

Huge directories are many ways bad.

1 Like
4

Thanks DGPcikett,

I have tried the command but not working...

 find /edw_qa -mount -type d | xargs -r ls -sd | sort -nr | pg
xargs: illegal option -- r
xargs: Usage: xargs: [-t] [-p] [-e[eofstr]] [-E eofstr] [-I replstr] [-i[replstr]] [-L #] [-l[#]] [-n # [-x]] [-s size] [cmd [args ...]]

This is Solaris

uname -a
SunOS dencdbbi2.cricketcommunications.com 5.10 Generic_147440-15 sun4u sparc SUNW,SPARC-Enterprise
5

The xargs option we want is to not run with nothing, so try -n999 in place of -r.

6

Thanks you sir,

It worked but its says 0 in lost+found dir.

7

Well, where the inodes hide until closed varies with operating system and perhaps with file system. With Solaris, /proc suffices. Some of the file names in there give device and inode by number, as I recall, and may also be there as /dev/fd/some-number. Some file systems can actually lose track of space with overload, and need a reboot or more to rebuild the fs.

8

lsof is also useful, check out the table to see what references are to that specific mountpoint and check those pids / files.