vx_nospace

[Konrad Hegner]

The output of dmesg-command is "vxfs: mesg 001: vx_nospace - /dev/root file system full (1 block extent), but the output of the bdf-command says 8% for the root partition (every partition hasn't more than 48%). What is the problem on this machine? Thank you.

[Christopher McCray_1]

What was the timestamp of the message? didi it coincide with any jobs you had running and werre there any errors associated with them.

Just some thoughts
regards
Chris

[A. Clay Stephenson]

Hi Conrad:

An error was logged so that at some time root was full. The process terminated and the offending file was unlinked. When you do your bdf, it is after the fact.

By the way, for all practical purposes the root filesystem should never grow; you need to find the cause of the filesystem filling. You may have core files or there may be file entries rather than device nodes in /dev. A very common thing is to have file like /dev/rmt/Om (the letter 'O' when you meant 0m (zero).

Clay

[James R. Ferguson]

Hi:

It looks as if your filesystem was once full and now isn't.

Look in /var/adm/syslog/syslog.log for the message and timestamp.

Regards!

...JRF...

[Michael Tully]

Hi Konrad,

One thing to note from your posting other
than the space problem which the other
guys have dealt with is that your report
shows as '/dev/root' as opposed to what it
should show and that is '/dev/vg00/lvol3'.
To fix this problem have a look at the
below link:

http://us-support.external.hp.com/cki/bin/doc.pl/sid=adad2bd005f5f08d90/screen=ckiDisplayDocument

my 2 cents worth

-Michael

[Josh_13]

i agree with michael, it sounds like you might have a mounting error that's complicating the problem. check to make sure everything is mounted correctly (i just had to deal with that since i moved opt and var to a different disk)

after that, if you're having problems where's there's actually a lack of space, check to see if your du has the -x option.

du -x will give you everything affecting the space fo that partition.

-Josh

[D. Jackson_1]

Most likely there was a "core" file that filled up /, the core file was removed and / is now okay. The output from dmesg will hold this message till it is over written by another event or till the system is rebooted. Syslog is more accurate as far as time is concerned, a reboot of the system will flush the kernel log/dmesg output.

HTH