dmesg output

[Keely Jackson]

Hi

I am getting the following output from dmesg -

vxfs: mesg 001: vx_nospace - /dev/vg00/lvol8 file system full (1 block extent)

/dev/vg00/lvol8 is /var and if I do a bdf it shows as 14% used.

/dev/vg00/lvol8 716800 96569 595023 14% /var

Please could someone explain why these messages occur and if I should be unduly concerned.

Many thanks

Keely

[Stefan Farrelly]

Just because you had an error which shows it was full at some point doesnt mean it is now. Check for full messages in /var/adm/syslog/syslog.log to get a time when this happened.

Whenever a disk fills up you should be worried. But var and tmp are a little different as they are used for temporary files (/tmp and /var/tmp) so as long as they dont stay full I wouldnt be too worried - unless someone complains their job failed due to running out of space. You should definitely keep a closer eye on /var so that if its starting to fill up you can track who/what is doing it.

You also need to be concious that some files can be left open which means bdf wont update and even ls -l wont show the true size of a file - but dmesg and syslog could report a filesystem full condition. In this case tracking down the open file which is causing it is difficult. You can do a search on these forums for "open files" to see how to track these down.

[Bill McNAMARA_1]

Use
fuser -cu
to find which processes have files open for /usr/

perhaps a file was rm -f'd but still open by a process..

Later,
Bill

[Dietmar Konermann]

Keely,

the bdf command uses statfsdev(3C) to get the file system statistics. If some unlinked but still open files would exist then the occupied space would be included in that statistics... so it is usually not possible that open files occupy space while bdf is showing that space as free.

Same for ls -l output. You see here the logical size of the file. The physical consumed space on disk can be only _less_ (in case of sparse files). So bdf cannot show too much free space here also.

I think the theory that the file system WAS full and is NOW free, is the most realic. A simple failed copy job with cleanup on failure whould show you the symptom.

You may simply check if the fs is full by trying to copy some stuff to it.


Regards...
Dietmar.

[Joaquin Gil de Vergara]

Perhgaps there are any corruption in file system

run the fsck command (previous umount) to fix any possible error

[Bill Hassell]

xdmesg by itself does not provide a timestamp so this error may have occurred several days, maybe several weeks ago and the problem was fixed back then.

To get a timestamp for dmesg, put this entry into root's crontab:

0,10,20,30,40,50 * * * * /usr/sbin/dmesg - >> /var/adm/dmesg.log

(be sure to put the - right after dmesg--this causes dmesg to append only new information) dmesg will also add a date for every new block of messages.

Now you can check /var/adm/dmesg.log to see when a particular error occurred. Remember to trim this log (and the others in /var/adm) on a regular basis.

[Keely Jackson]

Hi everyone

I downloaded lsof and had a look at fuser as suggested but as I'm not really sure how to interpret the results it wasn't a lot of help. RTFM of the man pages required!

The messages are output via a cron job, so they do have a time stamp. This particular machine doesn't do very much, it is used for the omniback cell manager, maestro and ITO. These messages have not come out again since so I can only assume I missed whatever was happening. I will jsut have to keep an eye on it.

Thanks for your help.

Cheers
Keely