help with disk space

[nitinkgoud]

Hi Guys,
When I do a df -h on serv1 I get this:

/dev/vx/dsk/systoolsdg/logs
10G 7.4G 2.5G 75% /logs

When I do a df -h on serv2 I get this:

/dev/vx/dsk/systoolsdg/logs
10G 2.2G 7.3G 24% /logs

So I go and do a du -h in /logs to see where all my space is being consumed and I get this on serv1:

0K ./lost+found
13M ./bea/wily
0K ./bea/reporting/temp
203K ./bea/reporting/log
2.3M ./bea/reporting/bin/lib
19K ./bea/reporting/bin/log
2K ./bea/reporting/bin/property
2.3M ./bea/reporting/bin
30M ./bea/reporting
4.3M ./bea/10s/wli_pkds0190_01
35M ./bea/10s/wli_pkds0190_02
33M ./bea/10s/wli_pkds0190_03
73M ./bea/10s/wli_pkds0190_04
0K ./bea/10s/wliAdmin
3.1M ./bea/10s/allchannel_admin
3.9M ./bea/10s/allchannel_01
152M ./bea/10s
993K ./bea/10sallchannel_01
196M ./bea
11M ./10S/pos/app_logs
11M ./10S/pos
11M ./10S
1.3M ./1IP/esi_sbprod
10M ./1IP/esi_wliprod
11M ./1IP
219M .

And when I do du -h on serv2:

0K ./lost+found
6.0M ./bea/wily
203K ./bea/reporting/log
2.3M ./bea/reporting/bin/lib
18K ./bea/reporting/bin/log
2K ./bea/reporting/bin/property
2.3M ./bea/reporting/bin
30M ./bea/reporting
0K ./bea/10s/wliAdmin
524M ./bea/10s/wli_pkds0191_02
541M ./bea/10s/wli_pkds0191_01
557M ./bea/10s/wli_pkds0191_03
533M ./bea/10s/wli_pkds0191_04
42M ./bea/10s/allchannel_02
2.1G ./bea/10s
2.2G ./bea
11M ./10S/pos/app_logs
11M ./10S/pos
11M ./10S
0K ./1IP/filexfer/rbtemi/archive
0K ./1IP/filexfer/rbtemi/cronlogs
18K ./1IP/filexfer/rbtemi
18K ./1IP/filexfer
9.5M ./1IP/esi_wliprod
907K ./1IP/esi_sbprod
14M ./1IP/esi_wliprod_mq
0K ./1IP/filexfer_old/rbtemi/archive
0K ./1IP/filexfer_old/rbtemi/cronlogs
0K ./1IP/filexfer_old/rbtemi
0K ./1IP/filexfer_old/rbtemiold/archive
0K ./1IP/filexfer_old/rbtemiold/cronlogs
0K ./1IP/filexfer_old/rbtemiold/precontrolm/archive
0K ./1IP/filexfer_old/rbtemiold/precontrolm/cronlogs
123K ./1IP/filexfer_old/rbtemiold/precontrolm
128K ./1IP/filexfer_old/rbtemiold
128K ./1IP/filexfer_old
24M ./1IP
2.2G .

What i would like to know is why dose size of . on serv2 matches the df -h output, but not on serv1?

 

[djr111]

Since there seems to be some type of logging mechanism righting to that filesystem. I have seen on serveral ocassions that unless you stop/restart or hup the process/script/logger, whatever it may be, it will not let go of the previously allocated space. The system has the space marked as open and is probably waiting for writes. I have seem this many of times for audit logging.


David

 

[Annihilannic]

If you get lsof from SunFreeware.com you can use that to identify file handles that are still open for deleted files (look for (deleted) in the output).

Annihilannic.

 

[smishra]

Hi,

is there any script or command readily available to identify file handles that are still open for deleted files ? I don't have the liberty to install lsof in my server.

Thanks in Advance.
smishra

 

[KenCunningham]

smishra, lsof is what you want, but if you're not at liberty to install it, I suggest you make a case to your management in the hope that they'll see sense and allow it. It's a pretty standard and valuable piece of software.

I don't mind people who aren't what they seem. I just wish they'd make their mind up.

 

[Annihilannic]

The only built-in utility for querying open files that I'm aware of is pfiles (sometimes located in /usr/proc/bin), however it makes no distinction between files that still exist and files that are deleted:

[tt]# ksh -c "while sleep 60 ; do date ; done" > ksh.out &
[1] 872
# ls -l
total 16
-rw------- 1 sys sys 0 Nov 20 08:00 croutYIYZ5VyAa
-rw-r--r-- 1 root other 0 Nov 20 08:35 ksh.out
# pfiles 872
872: ksh -c while sleep 60 ; do date ; done
Current rlimit: 256 file descriptors
0: S_IFCHR mode:0620 dev:85,0 ino:122976 uid:666 gid:7 rdev:24,5
O_RDWR|O_NOCTTY|O_LARGEFILE
1: S_IFREG mode:0644 dev:0,2 ino:30138903 uid:0 gid:1 size:0
O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE
2: S_IFCHR mode:0620 dev:85,0 ino:122976 uid:666 gid:7 rdev:24,5
O_RDWR|O_NOCTTY|O_LARGEFILE
4: S_IFREG mode:0644 dev:85,0 ino:87026 uid:1 gid:1 size:114688
O_RDWR|O_CREAT|O_LARGEFILE
5: S_IFREG mode:0644 dev:85,0 ino:87027 uid:1 gid:1 size:565248
O_RDWR|O_CREAT|O_LARGEFILE
# find . -inum 30138903
./ksh.out
# rm ksh.out
# ls -l
total 16
-rw------- 1 sys sys 0 Nov 20 08:00 croutYIYZ5VyAa
# pfiles 872
872: ksh -c while sleep 60 ; do date ; done
Current rlimit: 256 file descriptors
0: S_IFCHR mode:0620 dev:85,0 ino:122976 uid:666 gid:7 rdev:24,5
O_RDWR|O_NOCTTY|O_LARGEFILE
1: S_IFREG mode:0644 dev:0,2 ino:30138903 uid:0 gid:1 size:0
O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE
2: S_IFCHR mode:0620 dev:85,0 ino:122976 uid:666 gid:7 rdev:24,5
O_RDWR|O_NOCTTY|O_LARGEFILE
4: S_IFREG mode:0644 dev:85,0 ino:87026 uid:1 gid:1 size:114688
O_RDWR|O_CREAT|O_LARGEFILE
5: S_IFREG mode:0644 dev:85,0 ino:87027 uid:1 gid:1 size:565248
O_RDWR|O_CREAT|O_LARGEFILE
# find . -inum 30138903
#[/tt]

So it would be difficult to script around it unless you searched for every single inode open by every process looking for the one that doesn't come up, keeping in mind that you have to know which filesystem to search on (possibly derived from the dev number).

Annihilannic.