I will take back what I said about rebooting fixed the problems. It
didn't. I still have the problem. I actually called Compaq Tech Support.
/: write failed, file system is full
I received another e-mail to try this:
[UNIX] HowTo: Clean up a Corrupted Binary Errlog
Any party granted access to the following copyrighted information
(protected under Federal Copyright Laws), pursuant to a duly
executed
Compaq Service Agreement may, under the terms of such agreement
copy
all or selected portions of this information for internal use and
distribution only. No other copying or distribution for any other
purpose is authorized.
Copyright Compaq Computer Corporation 1999. All rights reserved.
COMPONENT: ERRLOG
OP/SYS: Digital UNIX (all versions)
QUESTION:
Due to problems running uerf or dia, you suspect the binary errlog
may be corrupted. How can you clean up the error log?
ANSWER:
It is not uncommon to get a corrupted entry in the binary error log.
It is not indicative of a system failure, but it would be
prudent to clean out the error log so that any valid errors
that may be logged don't become corrupted as well.
Here are the commands to copy the old binary errlog and start
a new one:
# cd /var/adm
Rename current errlog
# mv binary.errlog binary.errlog.old
Stop errlog process
# kill `cat /var/run/binlogd.pid` (These ` marks are not
single quotes. Please use
the key to the left of the
number 1 on your keyboard
for this hash mark ` )
Restart errlog process
# /usr/sbin/binlogd
Make a test entry into errlog
# /usr/bin/logger -b TEST
Check for test entry
# uerf -R -o full
To avoid this corruption, which is caused by too small a kernel
preserved message buffer, add the the "message-buffer-size",
"binlog-buffer-size" and "msgbuf_size" parameters to the
/etc/sysconfigtab file in the generic subsystem.
The value below has been shown to work on an Alphaserver 8400 with
several buses. Increase this value until corruption of the
binary.errlog no longer occurs.
generic:
message-buffer-size = 40960
binlog-buffer-size = 40960
msgbuf_size = 40960
For the change to take effect, you will need to reboot the system
with the modified /etc/sysconfigtab file.
This didn't work either!!
Lisa
----- Forwarded by Lisa Morris/VRD/Dana on 10/12/2001 02:29 PM -----
Lisa.Morris_at_victorreinz.
com To: tru64-unix-managers_at_ornl.gov
Sent by: cc:
tru64-unix-managers-owne Subject: SUMMARY: File system is full
r_at_ornl.gov
10/12/2001 12:22 PM
Thanks to everyone on all the ideas they gave me - unfortunately nothing
worked - so when all else fails - reboot!! Once I did this everything is
okay. Here are some of the great ideas everyone gave me:
/: write failed ---> indicate that the "/" (root filesystem) is
the one causing the problem. As you can see with "df" the / filesystem
is the root_domain#root that appear in the listing you put in your
email. It seem it just have 188816/2 KB free.. I divide by 2 because
your listing is in blocks of 512 bytes and not on Kilobytes. You
can issue "df -k" to see a listing in Kilobytes. Well 90 MB of free
space on / could be quite small because some programs use /tmp
as the temporal directory to put temporary data and depending on
the programs your users are running this 90 MB may be too small.
Is it possible that you repartition your hard disk? if not try
making a link of /tmp to /usr/tmp:
# rm /tmp
# ln -s /usr/tmp /tmp
this will make the programs that use /tmp actually use /usr/tmp
instead and then not run out of free space your small "/"
Probably your /tmp is momentarily filled up by something dynamic
Try running fuser/lsof on / and maybe /var as well if it's not a separate
mount point. You can get a situation whereby a process has a lock on a
file even after that file has been deleted. Therefore the filesystem
reports the space as still being in use even though it's actually free.
I think you've run into the BMT exhaustion problem. I'm guessing that
you're running 4.0x, or at least your AdvFS filesystem still is. One
way to find out for sure is go into the / directory, then the .tags
directory, and issue the following command:
# showfile -x M-6
The bottom line will say
extentCnt: xxx
Where the number is probably 683, which means that you are out of
metadata space.
Received on Fri Oct 12 2001 - 19:32:42 NZDT