AdvFS: "Large BMT extentCnt", "BMT pageCnt is decreasing"?

Dr. Hans Ekkehard Plesser · *nix forums beginner Joined: 15 Jan 2004 Posts: 18

Hi!

I am running V5.1B-3 with all current ERPs installed on a GS1280. I am using
AdvFS. All file domains were created with Version 4 AdvFS data structures.

sys_check v139 reports a "Large BMT extentCnt (861)" on one of my domains,
"BMT pageCnt is decreasing" on another. For details, see below.

I have tried verify -f and defragment on the domain with 861 extents, but that
has not changed the number of extents. I found earlier postings refering to
Tru64 V4.0 that suggested recreating the domain with -p and -x options to
mkfdmn (or addvolume), but documentation states that these options are not
applicable for domains with Version 4 AdvFS data structures.

I would therefore ask for you advice:

- Are the messages anything to worry about in terms of performance or data
integrity?

- If so, how can I reduce the number of extents? Should I use the
addvol/rmvol/addvol/rmvol cycle suggested in other postings to rebuild my
domain in a "clean" fashion? Will addvol then size the BMT properly
automagially?

- Any other suggestions (I guess using single 400GB partitions isn't optimal
for AdvFS, nor having users creating millions of 10-byte files ...)?

Thanks a lot in advance!
Hans E Plesser

Details:

sys_check v139 reports a large BMT extentCnt (861) on one of my domains.
nvbmtpg reports:

==========================================================================
DOMAIN "nlh_domain" VDI 1 (/dev/rdisk/dsk3c) lbn 48 BMT page 0
--------------------------------------------------------------------------
There are 235266 pages in the BMT on this volume.
The BMT uses 861 extents (out of 897) in 29 mcells.

Assuming that any BMT pages with 28 free cells are entirely empty (see
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=716675),
I find that some 153000 pages in the BMT are empty. showfile -x reveals that
all but the first three extents have 128 pages and 2048 blocks.

The domain contains three filesets with altogether some 150000 directories
with about 2 million files. The data is stored on a single volume (an ADG
RAID with 407GB capacity).

On another domain, sys_check complains that the "BMT pageCnt is decreasing".
Here nvbmtpg reports:

==========================================================================
DOMAIN "scratch_domain" VDI 1 (/dev/rdisk/dsk4c) lbn 48 BMT page 0
--------------------------------------------------------------------------
There are 46851 pages in the BMT on this volume.
The BMT uses 141 extents (out of 673) in 22 mcells.

Only som 481 pages appear to be empty. showfile -x shows that most extents
have just between 1 and 8 pages. This domain contains a single fileset with
about 1 million files. Data is stored on a single volume (RAID0 with 271GB
capacity).

--
Dr. Hans Ekkehard Plesser
Associate Professor
Dept. of Mathematical Sciences and Technology
Norwegian University of Life Sciences
Phone +47 6496 5467
Fax +47 6496 5401
Home http://arken.umb.no/~plesser

Dr. Hans Ekkehard Plesser · *nix forums beginner Joined: 15 Jan 2004 Posts: 18

Dear Managers!

Finally, a most belated summary on a question I posed last December. The
answers came in swiftly as usual, but testing them required several 100GB of
extra disk space, so I did not get around to it before now. And I did not
want to post a summary before testing myself.

My problem as that sys_check reported "Large BMT extentCnt" and "BMT pageCnt
is decreasing" on some of my AdvFS domains. Advice from Rob Leadbetter and
Thomas Sjolshagen was as follows:

- Avoid having too many small files.
- Defragment your disk regularly, or have vfast defragment it in the
background continuously.
- If you can afford the extra diskspace, turn off the frag-file option.
You can check frag file size with

# cd /mountpoint/.tags
# ls -l 1

- To "cure" a domain that has huge frag files or BMT problems, get extra disks
that can hold all your data and then either

# vdump -0f - /oldmountpoint | vrestore -xf - -D /newmountpoint

or (preferred) go through an addvol/rmvol cycle (dsk4c is my regular disk,
dsk16c a temporary disk):

/usr/sbin/addvol /dev/disk/dsk16c scratch_domain
/usr/sbin/rmvol /dev/disk/dsk4c scratch_domain

/usr/sbin/addvol /dev/disk/dsk4c scratch_domain
/usr/sbin/rmvol /dev/disk/dsk16c scratch_domain

The first two lines moved all data to dsk16, the second moved it all back to
dsk4. Use showfdnm to check progress. This worked perfectly for me. I kept
users off the machine while doing this.

Best regards,
Hans E Plesser
On Friday 02 December 2005 10:22, Dr. Hans Ekkehard Plesser wrote:

Google