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:
> 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
Email hans.ekkehard.plesser_at_umb.no
Home http://arken.umb.no/~plesser
Received on Tue Jul 04 2006 - 08:36:36 NZST