We have now established that the problem is the mkfdmn command ,
The following message identified the problem,
You ran out of Metadata Bitmap Extensions ... these are needed by Advfs to
create metadata for inodes ....
You shall initialize the advfs domain with an increment value for the
extends see the man page for mkdfmn
The man page quotes the following,
_______________________________________________________________
Number of Files BMT Size in pages
Suggested BMT Extent
Size in pages
_______________________________________________________________
Less than 50,000 default (128) 3,600
100,000 256 7,200
200,000 512 14,400
300,000 768 21,600
400,000 1024 28,800
800,000 2048 57,600
Does anyone know the consequences of going over this number of files, we estimate we would need to allow for
6,400,000 files per 72Gb domain? The table implies that,
6,400,000 would need 16,384 Suggested BMT Extent Size in pages, and 460800 BMT Size in pages.
Any ideas?
Bryan.
-----Original Message-----
From: bryan.mills_at_lynx.co.uk [SMTP:MIME :bryan.mills_at_lynx.co.uk]
Sent: Tuesday, August 21, 2001 9:56 AM
To: Bryan Mills; tru64-unix-managers_at_ornl.gov
Subject: UPDATE 2: RE: advfs
-------------------------------------------------------------------------- --
Also if we remove an empty directory,
rmdir bryan
and then create some files
touch bryan1
touch bryan2
touch bryan3
they all work
touch bryan4
results in
touch: bryan4 cannot create
This suggests the directory itself, '.' and '..'
Bryan.
-----Original Message-----
From: bryan.mills_at_lynx.co.uk [SMTP:MIME :bryan.mills_at_lynx.co.uk]
Sent: Tuesday, August 21, 2001 9:48 AM
To: tru64-unix-managers_at_ornl.gov
Subject: UPDATE:RE: advfs
--------------------------------------------------------------------------
--
Main suggestion so far seems to be inodes, but this does not seem to be
the case,
imgrep01 # df -ik|grep raidr1
raidr1#sqlbackup 71095408 2560184 36221288 7%
4 133684410 0% /images/sqlbackup
raidr1#2001-04 71095408 932 36221288 1%
150 133684264 0% /images/2001/04
raidr1#2001-05 71095408 2856 36221288 1%
470 133683944 0% /images/2001/05
raidr1#2001-06 71095408 7354003 36221288 17%
1280897 132403517 1% /images/2001/06
raidr1#2001-07 71095408 13238815 36221288 27%
2337189 131347225 2% /images/2001/07
raidr1#2001-08 71095408 8292806 36221288 19%
1495352 132189062 1% /images/2001/08
raidr1#2001-09 71095408 25 36221288 1%
4 133684410 0% /images/2001/09
raidr1#2001-10 71095408 17 36221288 1%
3 133684411 0% /images/2001/10
raidr1#2001-01 71095408 25 36221288 1%
4 133684410 0% /images/2001/01
raidr1#2001-03 71095408 469 36221288 1%
91 133684323 0% /images/2001/03
raidr1#2001-02 71095408 189018 36221288 1%
24094 133660320 0% /images/2001/02
imgrep01 #
-----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.
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 Tue Aug 21 2001 - 10:27:02 NZST