Thanks to all that replied (listed below) -- The reason why I had asked is
because we were thinking of converting our ~10,000 student email accounts
from /var/spool/mail format to Cyrus format (which stores messages 1 per
file similar to the old INN news server). A couple people from DEC replied,
and I'm including only those as they are definitive answers. To summarize,
upgrade to Tru64 5.0x, use AdvFS v4, make your domains, and never have to
worry about BMTs again..
The original message:
> When I used AdvFS v3, espectially on our news server, we got errors
similar
> to this: ENO_MORE_BLKS
> With AdvFS v4, there are no options to set the size of the page
increments,
> or even the base size of the BMT. Can I assume that in v4, I can just
make
> a file domain and fileset and never have to worry about how many files I
> expect to put put into this domain?
>
> Since we switched our news server to v4, we haven't seen these errors
> (yet) -- just wondering if they are gone for good...
The contributors:
S. Hancock(DEC), J Speno, A Davis, J.D. Brock, N Milutinovic, L Hercaud,
alan (DEC), T. Blinn (DEC)
The answers:
alan----------------------------------------------
Without going back to the message I got from one of the authors, the change
made in V4 was to set a "soft" area for growing the BMT and not use that
space until it was really needed for data. This made it more likely that
BMT problem wouldn't occur. In V5 they changed the affected data structure
so that it could have as many extents as needed. At least this is how it
think it works now. I think the affect is that it very unlikely to be a
problem on V4 and shouldn't be a problem at all on V5.
s. hancock---------------------------------------------
This is a complex question. The problem still exists in V4 (if we can talk
about V4 as a single entity) and the -x flag (to which you refer) still
exists in mkfdmn and addvol for every V4 version that I'm aware of. The
problem that you describe, which I will call the BMT exhaustion problem, has
been corrected with on-disk structure changes made in Tru64 UNIX 5.0. Since
you aren't there, yet, you can still encounter this problem.
It is less likely you will hit this problem in V4.0D and above, because of
changes in the way BMT allocations are made in V4.0D+. These version will
perform a "soft pre-allocation" of BMT os up to 1/5 of the size of the
volume. This assumes, of course, the domain was created or volume was added
at V4.0D or later. Volumes for domains created before V4.0D could already be
well on their way to being hightly fragmented and most likely will not be
able to take advantage of the soft-preallocation. What I mean by "soft
pre-allocation' is that the 1/5 of the volume is reserved for BMT expansion
as long as it
is not needed by other files. Therefore it will grow in a contiguous fashion
and not become fragemented. It is fragmentation of the BMT that causes the
BMT exhaustion problem. You may remember the -p flag which still exists in
V4.0 mkfdmn and addvol commands. This was a "hard pre-allocation" which
meant you were dedicating those blocks to the BMT up-front. Soft
pre-allocation is better, but the problem is not "fixed" until V5.
--------------"the AdvFS engineering manager" via Dr. Blinn---------
There are significant improvements in AdvFS in the V5.0 and later releases,
and these benefits are one of the reasons people should be planning to get
to the new releases (sooner rather than "some day when V4.0x breaks").
> The BMT exhaustion problem was eliminated with on-disk version 4
> domains in AdvFS. The on-disk structures were redesigned to
> remove this limitation. New domains created under 5.x are,
> by default, on-disk version 4 and will not exhibit the problem
> described by the customer. It is possible to create on-disk
> version 3 domains while running 5.x by using the -V3 flag to
> the mkdfmn command. In that case, the old mkfdmn and addvol
> flags to preallocate the BMT and control how it is extended
> are still applicable. We strongly encourage customers to use
> on-disk version 4 domains unless they have a pressing need to
> keep their domains mountable by systems running 4.x. This is
> because of the elimination of the BMT exhaustion problem, the
> advent of B-tree index files for fast directory lookup, smaller
> metadata disk usage, and other enhancements.
Received on Wed Mar 15 2000 - 16:58:43 NZDT