Time for a summary I think.
LHERCAUD_at_bouyguestelecom.fr
richard.tame_at_compaq.com
tyler_h_at_bellsouth.net
Seem to have been the main protagonists in this debate, but several other have also contributed.
We have concluded that the problem is with the allocation of the 'bitfile metadata table', BMT. When creating a disk domain using 'mkfdmn' the defaults only allow for 128 pages, or 50,000 files. Read the man page for more info and look at the '-x' and '-p' options. You can't change this on the fly, but we were fortunate to have two identical raid sets, one of which hasn't been implemented yet. If you feel like checking your BMT allocation to check you're not getting close to the limit use the command,
/sbin/advfs/vbmtpg /dev/rzc40c | pg
PAGE LBN 32 megaVersion 3 nextFreePg 0 freeMcellCnt 21 pageId 0
The top line shows 'freeMcellCnt' as 21, this is good. Previously ours said 0. This is bad!
Appparently this works differently in 5.x and above. This is handled automatically, but domains need to be recreated after an upgrade, it doesn't happen automatically.
Bryan.
-----Original Message-----
From: bryan.mills_at_lynx.co.uk [SMTP:MIME :bryan.mills_at_lynx.co.uk]
Sent: Tuesday, August 21, 2001 9:22 AM
To: tru64-unix-managers_at_ornl.gov
Subject: advfs
-------------------------------------------------------------------------- --
We have run into a problem this morning with an advfs configuration.
We have a raid array 8000 with a 72Gb partiton. We have several advfs
filesets mounted onto these, with 100 directories in each and then lots
of small binary files in each. This morning for no reason the fileset
has stopped allowing any new data being written into it, but a df -k
shows that there should be 32Gb still available. We have an identical 72
gb partion on the same raid array, and have filled this to 100% , but not
with so many individual small files, without problems which leads me to
suspect that we have blown a file count limit somewhere.
df -k looks like this,
raidr1#2001-04 71095408 932 36221288 1%
/images/2001/04
raidr1#2001-05 71095408 2856 36221288 1%
/images/2001/05
raidr1#2001-06 71095408 7354003 36221288 17%
/images/2001/06
raidr1#2001-07 71095408 13238815 36221288 27%
/images/2001/07
raidr1#2001-08 71095408 8292806 36221288 19%
/images/2001/08
raidr1#2001-09 71095408 25 36221288 1%
/images/2001/09
raidr1#2001-10 71095408 17 36221288 1%
/images/2001/10
Does anyone know what if any other limits we may have hit? I don't think
advfs has inodes? Any sugesstions greatly received.
Bryan Mills.
This message is intended only for the use of the person(s) ("The intended
Recipient(s)") to whom it is addressed. It may contain information which
is privileged and confidential within the meaning of applicable law. If
you are not the intended recipient, please contact the sender as soon as
possible. The views expressed in this communication are not necessarily
those held by LYNX Express Limited.
This message is intended only for the use of the person(s) ("The intended
Recipient(s)") to whom it is addressed. It may contain information which
is privileged and confidential within the meaning of applicable law. If
you are not the intended recipient, please contact the sender as soon as
possible. The views expressed in this communication are not necessarily
those held by LYNX Express Limited.
Received on Wed Aug 22 2001 - 14:58:47 NZST