it sounds like an oxymoron, doesn’t it? I saw it once many years ago. To day, a colleague of mine noticed it on one of his machines.
Look bellow, the
/epic/sup07 has a very little free space left.
/epic/sup07/ifc/stream> df -g . Filesystem GB blocks Free %Used Iused %Iused Mounted on /dev/sup07_lv 5.00 0.01 100% 9 1% /epic/sup07
After a closer inspection, we can locate only a pair of sub-directories, all empty.
/epic/sup07/ifc/stream> cd ../../ /epic/sup07> ls -l total 0 drwxr-sr-x 3 epicadm cachegrp 256 May 11 09:24 dcifc drwxr-sr-x 3 epicadm cachegrp 256 May 11 09:24 ifc drwxr-xr-x 2 root system 256 Nov 14 10:44 lost+found /epic/sup07> du -ak . | sort -nr | more
Yes, there is nothing here to see for us but there still may be something there like for example open files ….
We leave the file system so our presence does not distort it and execute the
lsof command against it.
/epic/sup07> cd /root> lsof /epic/sup07 In while loop:256 Value of I :61 np:256 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME cache 10289344 lyko cwd VDIR 37,39 256 2 /epic/sup07(/dev/sup07_lv) ksh 11993330 epicadm cwd VDIR 37,39 256 2 /epic/sup07(/dev/sup07_lv) dsmc 146 root 10 VREG 37,39 5360353284129/epic/sup07(/dev/sup07_lv) ksh 17694934 lyko cwd VDIR 37,39 256 2 /epic/sup07(/dev/sup07_lv)
Yes, there is a huge file in
/epic/sup07 created by the
dsmc command. After a further investigation and determination that no active backup/restore takes place we kill the offending process. By the way, in the last output we shortened the PID of the
dsmc in order to format the output to fit the screen. Here we go, killing the process.
/root> kill -9 14618974
Now, is there the free space or not?
/root> df -g /epic/sup07 Filesystem GB blocks Free %Used Iused %Iused Mounted on /dev/sup07_lv 5.00 4.98 1% 8 1% /epic/sup07
Well, we got back what was/is rightfully ours 🙂