vold.o really required when VxVM isn't used?

[Ralph Grothe]

Hi,

I found while doing a forums' search for vold.o
that this exceptionally large object file within rootfs was a common suspect for space consuming but probably not really needed files with regard to full / issues.

I am also a bit short of space in / and wonder if we really require this file to be resident in a *build* directory, let alone since we don't use VxVM on this box at all but LVM.
Isn't it common practice that after a build developers usually run a "make clean" when space is scarce and a soon relink with short recompile and processing time isn't really required?


# find / -xdev -type f -size +100000c -exec ll -d {} +|sort -k 5n|tail -3
-rw------- 1 root sys 10806272 Feb 9 11:24 /etc/lvmconf/vgsapz01.conf.old
-rw------- 1 root sys 11071488 Aug 9 2007 /etc/lvmconf/vgZ01.conf
-r-xr-xr-x 1 bin bin 29414983 Nov 4 2006 /etc/vx/static.d/build/vold.o

[James R. Ferguson]

Hi Ralph:

I would agree with your comments. If space is at a premium, you could always copy the 'void.o' object to another filesystem in the event that you need/want it. I don't use VxVM but it appears to me that your server did at one time, given the 'vgsapz01.conf.old' and 'vgZ01.conf' files (?).

Regards!

...JRF...

[Ralph Grothe]

Hi James,

yes, I should get rid of the vgZ01.conf and vgsapz01.conf.old in /etc/lvmconf.
The first dates back to an outdated LVM VG that no longer exists, and the latter is a backup that is available by the host's external backup/archiving anyway.

Interestingly, /etc can also fill up your / FS when you run ServiceGuard and have a lot of Packages an switching activity, and forget about each SG package's own log file.
However, here this is no issue since there is little switching/failing over and hence little logging.
But on other clusters of ours I already thought about symlinking to some logging dir on /var instead.

[Ralph Grothe]

But wait, what originally made me post this was that when I ran a vgcfgbackup on the shared VG on the standby node after having extended the shared VG by another SAN PV, I suddenly got this vxfs message (maybe only a coincidence?):

# dmesg|tail -1
msgcnt 1 vxfs: mesg 001: vx_nospace - /dev/root file system full (1 block extent)

I ran a find down /dev but could only see device files and symlinks in there.

Do you have an explenation for the sudden vx_nospace /dev/root message?

[Dennis Handly]

>Do you have an explanation for the sudden vx_nospace /dev/root message?

Why do you say sudden? You have no idea when that message was put into dmesg. Do you have something in syslog.log?
Do you have enough space in / now?

[Ralph Grothe]

Hi Dennis,

I said "sudden" because this message appeared right after I had issued vgcfgbackup.
I only rummaged it up from the dmesg ring buffer since it was shorter to type than grepping for it in syslog.log.
And I have abt. 10 MB still left free on /,
as was the case during the execution of vgcfgbackup (of course plus the abt. 7 MB that are now taken by the /etc/lvmconf/vgsapz01.conf)

Here is the error message's occurrence snipped out from syslog.log with preceding LVM commands for syncing of lvmconf of this shared VG with the primary node's.

Jun 22 13:08:39 warnow LVM[3746]: vgexport vgsapz01
Jun 22 13:13:55 warnow LVM[3929]: vgimport -v -s -m /tmp/vgsapz01.map vgsapz01
Jun 22 13:14:13 warnow LVM[3941]: vgchange -a r vgsapz01
Jun 22 13:14:45 warnow vmunix: msgcnt 1 vxfs: mesg 001: vx_nospace - /dev/root file syst
em full (1 block extent)

[Dennis Handly]

>I said "sudden" because this message appeared right after I had issued vgcfgbackup.

Ok. And syslog.log shows something similar.

>And I have about 10 MB still left free on /,
as was the case during the execution of vgcfgbackup

I can only assume that vgcfgbackup used up all of your space during that time.

[Ralph Grothe]

That's probably the case, presumably by some temporary copy.

[James R. Ferguson]

Hi Ralph:

You are probably aware of this but, remember that the default action for the LVM commands is to backup the volume group configuration into '/etc/lvmconf'. More importantly, the current file for the volume group is renamed with a '.old' suffix' and a new one created. If you are satisfied with the new configuration you could simply remove the '.old' file.

By the way, I misread and mis-spoke earlier when I said "... but it appears to me that your server did at one time, given the 'vgsapz01.conf.old' and 'vgZ01.conf' files...". Had I looked more carefully at the directory that you reported them in, I would have known that they were LVM (not VxVM) related.

Regards!

...JRF...