Thanks,
After replies from a few people listed below.....
The culprit is believed to be vrestore.
#ps -ef | grep vrestore
root 5286 10284 0.5 10:01:25 ttypN 5:39.59 vrestore -i -v -f
/dev/nrmt0h
Method:
#lsof /dev/nrmt0h
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
vrestore 5286 root 3r VCHR 9,20483 0x2ba331000 23418 /dev/nrmt0h
#lsof -p 5286
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
vrestore 5286 root cwd VDIR 40,5 512 5927448 /data
(/dev/vol/rootdg/vol01)
vrestore 5286 root txt VREG 11,0 475136 7930 / (/dev/re0a)
vrestore 5286 root txt VREG 11,0 139264 8051 /sbin/loader
vrestore 5286 root txt VREG 11,0 1579280 8032 /shlib/libc.so
vrestore 5286 root txt VREG 11,0 81920 7812 /shlib/libmsfs.so
vrestore 5286 root 0u VCHR 6,849 0t2639656 25118 /dev/pts/849
vrestore 5286 root 1u VCHR 6,849 0t2639656 25118 /dev/pts/849
vrestore 5286 root 2u VCHR 6,849 0t2639656 25118 /dev/pts/849
vrestore 5286 root 3r VCHR 9,20483 0x2c2a13000 23418 /dev/nrmt0h
vrestore 5286 root 4r VCHR 1,0 0t38 23053 /dev/tty
vrestore 5286 root 5u VREG 11,0 57490432 15383 / (/dev/re0a)
The last line being the one of particular interest. It appears to me that
the
program opens access and uses part of the "/" filesystem without reporting
it in
a directory entry, entry teh discrepancy between figures from df and du. It
also
means that you cannot see it with find (-mtime or -ctime).
Further info:
(Whilst vrestore was running)
#du -xsk /
62947 /
#df -k
Filesystem 1024-blocks Used Available Capacity Mounted
on
/dev/re0a 134473 116776 4249 97% /
/proc 0 0 0 100% /proc
/dev/re0g 3727563 2291048 1063758 69% /usr
/dev/re3f 4789422 2739518 1570961 64% /spool
/dev/re3g 1993663 397698 1396598 23% /temp
/dev/vol/rootdg/vol01 32420853 24889048 4289719 86% /data
And now that vrestore has finished (after 5 hours)...
#du -xsk
62947 .
#df -k
Filesystem 1024-blocks Used Available Capacity Mounted
on
/dev/re0a 134473 60592 60433 51% /
/proc 0 0 0 100% /proc
/dev/re0g 3727563 2291775 1063031 69% /usr
/dev/re3f 4789422 2769642 1540837 65% /spool
/dev/re3g 1993663 398762 1395534 23% /temp
/dev/vol/rootdg/vol01 32420853 24865023 4313744 86% /data
#
Many thanks to:-
John H. Warren, Phil Thomas , alan_at_nabeth.xxx.xxx.xxx ,
Jim Belonis , Roy Smith , Anthony Talltree , Stanley Horwitz
Further comments are welcome, especially if my thinking is wrong.
I am still a learning as I go.
Regards,
Jim Smart
The System Works Pty. Ltd.
Brisbane, Australia
-----Original Message-----
From: Jim Smart [mailto:jim_at_tsw.com.au]
Sent: Tuesday, 2 March 1999 11:46 AM
To: tru64-unix-managers_at_ornl.gov
Subject: root filling up with no visible trace ?
Hi,
I have not noticed this before yesterday, but....
The root file system seems to fill at times and a find -mount
for either ctime or mtime of 1 does not reveal the culprit(s) files.
This is how it looks now.
# df -k
Filesystem 1024-blocks Used Available Capacity Mounted
on
/dev/re0a 134473 116976 4049 97% /
/proc 0 0 0 100% /proc
/dev/re0g 3727563 2290665 1064141 69% /usr
/dev/re3f 4789422 2731404 1579075 64% /spool
/dev/re3g 1993663 396985 1397311 23% /temp
/dev/vol/rootdg/vol01 32420853 23501815 5676952 81% /data
#
The figures for the end of the day , yesterday were :-
Dir %Space_Used %INODES_used
/ 51% 16%
/usr 69% 3%
/spool 62% 6%
/temp 22% 0%
/data 81% 7%
This machine is an Alpha 4100 running DUnix V4.0b and UniVerse.
Further info:
Bash 2.03 #find / -mount -ctime 1 -exec ls -ld {} \; | grep -v -E
"^c|^b|^d|^l"
-rw-r--r-- 1 root system 79553 Mar 1 21:07 /etc/passwd
-rw-r--r-- 1 root system 8 Mar 2 10:41 /etc/ntp.drift
-rw-r--r-- 1 root system 160 Mar 2 04:10 /etc/vdumpdates
-rw-r--r-- 1 root system 819200 Mar 1 21:07 /etc/passwd.pag
-rw------- 1 root system 196608 Mar 2 04:18 /core
-rw------- 1 root system 8059 Mar 2 09:16 /.bash_history
Bash 2.03 #
Any help on how to find out where this space is going would be
veru much appreciated.
Regards,
Jim Smart
The System Works Pty. Ltd.
Brisbane, Australia
Received on Tue Mar 02 1999 - 08:24:23 NZDT