topic Re: strange problem with / used space in Operating System - HP-UX

strange problem with / used space

mohamed.bouraoui — Sun, 01 Aug 2010 15:14:02 GMT

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.

Re: strange problem with / used space

James R. Ferguson — Sun, 01 Aug 2010 15:41:22 GMT

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...

Re: strange problem with / used space

mohamed.bouraoui — Sun, 01 Aug 2010 15:45:40 GMT

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

Re: strange problem with / used space

Steven Schweda — Sun, 01 Aug 2010 16:16:31 GMT

> 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.)

Re: strange problem with / used space

mohamed.bouraoui — Sun, 01 Aug 2010 18:08:12 GMT

--->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)

Re: strange problem with / used space

James R. Ferguson — Sun, 01 Aug 2010 18:08:24 GMT

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...

Re: strange problem with / used space

Steven Schweda — Sun, 01 Aug 2010 19:42:29 GMT

> [...] 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).

Re: strange problem with / used space

doug hosking — Mon, 02 Aug 2010 00:08:26 GMT

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.

Re: strange problem with / used space

Mohammad Ashfaqur Rahma — Mon, 02 Aug 2010 03:18:04 GMT

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?

Re: strange problem with / used space

Dennis Handly — Mon, 02 Aug 2010 04:00:05 GMT

>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).

Re: strange problem with / used space

Minoia — Mon, 02 Aug 2010 05:30:44 GMT

It is not a bug.
The root filesystem is full.

Please try to find some big files on / with command find / -xdev -c 10000000c | xargs ll -d

This command list all files bigger the 10MB, please check the list and find the files those have not reason to stay on root file system

Re: strange problem with / used space

Bill Hassell — Mon, 02 Aug 2010 12:30:44 GMT

> /dev/vg00/lvol3 1572864 1572784 80 100% /

The root filesystem is full. A LOT of things are going to fail in this situation, not just un-zipping a file.

Do NOT look for big files, look for big directories:

du -kx | sort -rn | head -20

The two largest directories under / should be /sbin and /etc -- nothing else should come close to these directories in size. If so, someone has messed up your root directory. It also appears that you may have root's HOME directory in /, the default location, but a very bad place for root. Check the / directory for junk files (I call them root droppings):

ll / | sort -rnk5 | head -20

Never store large files in root's HOME.

Re: strange problem with / used space

V. Nyga — Tue, 03 Aug 2010 07:12:02 GMT

Hi,

> and also this a new installation

So can you repeat the installation?
How full is / then?

Can you 'view' (verbose) the zip file and check for big files?
Can you show us a listing of your zip file?

V.

Re: strange problem with / used space

Michael Sillers — Thu, 05 Aug 2010 14:13:04 GMT

I agree with Doug about the kernel allocating disk space. If you are running the unzip command from somewhere in the root filesystem, it may be creating a temporary file there and may still be stuck runnign somewhere in the background.

Since the error occured during the unzip, check to see if it is still running using ps -ef | grep zip.

If it is, kill it then try the bdf command again. That should free up the allocated disk space.

cd to the unzipped directory you mentioned and run the unzip command again to see if there is any difference.