From: Taylor, David (DTaylor@WBMI.COM)
Date: Tue Jul 09 2002 - 14:00:46 EDT
We recently ran into a situation, while reading the contents of several
optical platters back into magnetic cache, where we were unable to create
files larger than 32K, within this particular file-system. -- anything
larger than 32K was truncated to 32K and an error message was displayed.
I was informed by IBM that we had, essentially, exceeded a limitation of the
file-system. (which I found disturbing - not to mention the fact that the
O/S allowed me to continue to corrupt the file-system)
Even though I plan on applying the recommended fix (which doesn't seem like
a fix - merely increasing the finite number of files >32K that can be
created between reboots), does anyone know how I can monitor to prevent this
in the future?
I would hate to have to schedule regular-reboots for servers with high
file-system traffic.
Has anyone else run into this?
>From the APAR: (IY13763)
----------------------------------------------
Since the beginning of AIX there has been a single 256MB .indirect
virtual memory segment that is used to cache indirect inodes.
.
When you are copying many files that are greater than 32,768 bytes,
this 256MB .indirect segment fills up, and you get the ENOMEM error
and truncation of files. A reboot will clear out the cache, but
when/if the cache fills up you would see the problem return.
.
The APAR IY13763 allows you to use 8 256MB .indirect segments
for inode caching, IF you use "mount -o mind /filesystemname".
---------------------------------------------
David
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 22:16:02 EDT