strange problem with / used space

[mohamed.bouraoui]

Dear friends,
I have a strange problem with / used space.
I don't have any file take this space in /, and also this a new installation, the one action that I made is to unzip a zip file with message error:

vxfs: msgcnt 2 mesg 001: V-2-1: vx_nospace - /dev/root file system full (1 block extent)java.io.IOException: No space left on device (errno:28)

this a output on my bdf:

/dev/vg00/lvol3 1572864 1572784 80 100% /
/dev/vg00/lvol1 1776056 65648 1532800 4% /stand
16% /var
/dev/vg00/lvol7 4702208 1829648 2850192 39% /usr
/dev/vg00/lvol6 2097152 42144 2038984 2% /tmp
/dev/vg00/lvol5 10485760 3518200 6915256 34% /opt
/dev/vg00/lvol4 524288 16752 503576 3% /home


can someone aswer my strange problem? if it's a bug, can you forward my a bug correctif?
thanks for all.

[James R. Ferguson]

Hi:

Whatever you unzipped was written into the root directory ('/'). If the archive had absolute paths to its contents, then this would be the default expectation.

You need to find and remove whatever you loaded.

Regards!

...JRF...

[mohamed.bouraoui]

no, I unzip to the other directory.
and no new folder has been created on /.

[Steven Schweda]

> I don't have any file take this space in
> /, [...]

You know this how?

> [...] unzip a zip file [...]

How, exactly?

> [...] /dev/root file system full [...]

What is "/dev/root"?


> [...] I unzip to the other directory.

_Which_ "the other directory"?

> [...] no new folder has been created on /.

You know this how? Did you look in "/dev"?
The problem is in the "/" _file_system_, not
necessarily in the "/" _directory_.


As usual, showing actual commands with their
actual output can be more helpful than vague
descriptions and interpretations. What you
believe may be interesting, but what the
system tells you is probably more valuable.
(Sadly, with my weak psychic powers, I can't
see it if you don't show it.)

[mohamed.bouraoui]

--->You know this how?
using : touch -mt /tmp/201007281400 aslam, find / -xdev -type f -newer /tmp/aslam -exec ls -l -b {} +|sort -rnk5

the output is:
-r-xr-xr-x 1 bin bin 425984 Aug 1 14:56 /sbin/reboot.prev
-rw-r--r-- 1 root root 385024 Aug 1 15:13 /etc/opt/resmon/log/api.log
-rw------- 1 root sys 78848 Jul 28 17:57 /etc/lvmconf/vg01.conf.old
-rw------- 1 root sys 78848 Jul 28 17:57 /etc/lvmconf/vg01.conf
-rw-r----- 1 root mail 24576 Aug 1 15:05 /etc/mail/aliases.db
-rw-r--r-- 1 root root 23678 Aug 1 15:05 /etc/rc.log.old
-rw-r--r-- 1 root root 23570 Aug 1 15:06 /etc/rc.log
-rw-r--r-- 1 root sys 16036 Aug 1 14:56 /etc/opt/resmon/log/client.log
-rw------- 1 root sys 9316 Jul 28 17:51 /etc/lvmtab
-rw-rw-rw- 1 root sys 8192 Aug 1 15:11 /Disk1/stage/Components/oracle.assistants.acf/10.2.0.1.0/1/DataFiles/filegroup1.jar
-rw-r--r-- 1 root root 8192 Aug 1 15:13 /etc/opt/resmon/log/registrar.log
-rw-r--r-- 1 root root 8140 Aug 1 15:12 /etc/opt/resmon/persistence/m.3804569199
-r-------- 1 bin bin 6959 Aug 1 15:05 /etc/SnmpAgent.d/snmpd.conf
-rw-r--r-- 1 root sys 5884 Aug 1 15:22 /etc/ioconfig
-rw-r--r-- 1 root root 5832 Aug 1 15:05 /etc/utmps
-rw------- 1 root sys 5757 Aug 1 17:47 /.bash_history
-rw-r--r-- 1 root sys 5605 Aug 1 15:06 /etc/opt/resmon/log/emsagent.log
-r-xr--r-- 1 root sys 4823 Aug 1 13:16 /sbin/init.d/ipfboot.bak
-rw-rw-rw- 1 root sys 4702 Aug 1 15:11 /Disk1/stage/Components/oracle.assistants.acf/10.2.0.1.0/1/DataFiles/filegroup2.jar
-r--r--r-- 1 root root 4270 Aug 1 15:06 /etc/dt/config/Xservers
-rw-r--r-- 1 root sys 3081 Aug 1 13:20 /.sw/sessions/1856
-rw-r--r-- 1 root root 2717 Aug 1 15:12 /etc/opt/resmon/persistence/m.1533300606
-rw-r--r-- 1 root root 2626 Aug 1 15:12 /etc/opt/resmon/persistence/m.3292848383
-rw-r--r-- 1 root root 2586 Aug 1 15:12 /etc/opt/resmon/persistence/m.1998375097
-rw-r--r-- 1 root root 2541 Aug 1 15:12 /etc/opt/resmon/persistence/m.3111254123
-rw------- 1 root root 2520 Aug 1 17:47 /etc/utmpx
-rw-r--r-- 1 root root 2274 Aug 1 15:09 /etc/opt/resmon/persistence/m.2414940221
-rw-r--r-- 1 root root 2232 Aug 1 15:09 /etc/opt/resmon/persistence/m.542229
-rw-r--r-- 1 root root 1898 Aug 1 15:08 /etc/opt/resmon/persistence/m.3376148974
-rw-r--r-- 1 root sys 1535 Aug 1 15:29 /.sw/sessions/swremove.last
-rw-r--r-- 1 root sys 1531 Aug 1 14:21 /.sw/sessions/4267
-rw------- 1 root sys 1202 Aug 1 15:06 /etc/opt/resmon/log/emsha.log
-rw-r--r-- 1 root root 1173 Aug 1 15:05 /etc/mnttab

when we look the size of each those files , all them do not exceed 400k

---->How, exactly?
using /usr/local/bin/unzip p6810189_10204_HPUX-IA64.zip -d /var/unzipedfiles/

---->What is "/dev/root"?
is /
---->no new folder has been created on /.
for me the size of / without size of all monted filessytem (/var, /tmp, /opt, /stand, /usr, /home)

[James R. Ferguson]

HI (again):

> no, I unzip to the other directory.
and no new folder has been created on /.

What directory? Did you 'cd' into something like '/etc'? This isn't a separate mount point and hence is part of the '/' filesystem.

DId you inadvertently create a regular file in '/dev' by meaning to write '/dev/rmt/0m' but instead saying '/dev/rmt/om' [using the letter "o"]?

As for the error message, '/dev/root' is what the kernel calls the '/' mountpoint (filesystem).

I presume that the message you pasted is from 'dmesg' and could be old. However, the 100% utilization of '/' is a problem.

Why can't you show the actual commands that you used to "unzip a zip file"? Are you using the terms "zip" in a general sense or do you specifically mean the 'zip' utility? I ask, because 'zip' isn't a part of the core HP-UX software.

While you may not have any one large file, in the root filesystem, you may have added a number of files that are consuming too much space. Look for large directories:

# du -xk / | sort -krn1,1

Again, your limited problem statement says that "...the one action that I made...". So what was that action (the command(s)) and what was the expected outcome (e.g. the deposition of some file and/or the creation of some directory)?

Regards!

...JRF...

[Steven Schweda]

> [...] find / -xdev -type f -newer [...]

Do you think that an UnZip program can't
set the date-time attributes of a file when
it extracts it? You said, "I don't have any
file [...]", not "I don't have any _new_ (or
_new-looking_) file [...]".


> [...] 'zip' isn't a part of the core HP-UX
> software.

The usual Info-ZIP UnZip program is a C
program, and is not likely to trigger an
error message which says anything like
"java.io.IOException". I assume (which, of
course, I shouldn't need to do) that this
complaint comes from some Java-related "jar"
thing (which is [Un]Zip-compatible).

[doug hosking]

A common problem in this situation is that a large file has been deleted, but is still open by some application. Until the last application with that file open closes it, the space it occupies is not actually freed by the kernel. When this occurs, it can LOOK like there are no large files on the system even though they actually still exist on disk.

Tools such as lsof can help find these files, but a simpler way is sometimes just to reboot the system, which will of course terminate all applications. If you try the reboot approach, it would be good to do the next reboot into single user mode, to avoid complications in case that approach didn't correct the problem.

[Mohammad Ashfaqur Rahma]

Dear,

1. where is your /etc ? is that under / ?
2. have u measure the size of the hidden file under / ? (like - .sh_history, .Xauthority etc?

[Dennis Handly]

>also this a new installation

Unless you find some bogus files in /dev/ or elsewhere, it appears you didn't allocate enough space to /.

>if it's a bug, can you forward me a bug corrective?

Perhaps it's a sysadmin bug, do you have any sticks handy? :-)

>Mohammad: 2. have you measured the size of the hidden files under /?

For root, these aren't hidden. Nor are they hidden from find(1).