niXforums Forum Index
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   PreferencesPreferences   Log in to check your private messagesLog in to check your private messages   Log inLog in 
·  nixdoc.net ·  man pages ·  Linux HOWTOs ·  FreeBSD Tips ·  Forums
navigation Forum index » *nix » Tru64 » Tru64 managers mail-list
AdvFS: "Large BMT extentCnt", "BMT pageCnt is decreasing"?
Post new topic   Reply to topic Page 1 of 1 [2 Posts] View previous topic :: View next topic
Author Message
Dr. Hans Ekkehard Plesser
*nix forums beginner


Joined: 15 Jan 2004
Posts: 18

PostPosted: Tue Jul 04, 2006 8:34 am    Post subject: SUMMARY: AdvFS: "Large BMT extentCnt", "BMT pageCnt is decreasing"? Reply with quote

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:
Quote:
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@umb.no
Home http://arken.umb.no/~plesser
Back to top
Dr. Hans Ekkehard Plesser
*nix forums beginner


Joined: 15 Jan 2004
Posts: 18

PostPosted: Fri Dec 02, 2005 9:22 am    Post subject: AdvFS: "Large BMT extentCnt", "BMT pageCnt is decreasing"? Reply with quote

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
Back to top
Google

Back to top
Display posts from previous:   
Post new topic   Reply to topic Page 1 of 1 [2 Posts] View previous topic :: View next topic
The time now is Sat Nov 22, 2008 12:35 pm | All times are GMT
navigation Forum index » *nix » Tru64 » Tru64 managers mail-list
Jump to:  

Similar Topics
Topic Author Forum Replies Last Post
No new posts new installation not finding large memory Miles Fidelman Debian 8 Thu Jul 20, 2006 9:00 pm
No new posts wxPython: wxStaticBitmap and large images Roger Miller python 1 Wed Jul 19, 2006 11:27 pm
No new posts large enterprise accounting package available? Tshepang Lekhonkhobe Debian 2 Wed Jul 19, 2006 1:30 pm
No new posts How to copy a large innodb table Dominik Klein MySQL 2 Mon Jul 17, 2006 12:28 pm
No new posts Clustering and backup with large objects Marco Bizzarri PostgreSQL 0 Thu Jul 13, 2006 7:25 pm

Debt Consolidation | Business Credit Card | Xbox Mod Chip | Loans | Western Union Money Transfer
Copyright © 2004-2005 DeniX Solutions SRL
 
Other DeniX Solutions sites: Unix/Linux blog |  electronics forum |  medicine forum |  science forum | 
Privacy Policy


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.2486s ][ Queries: 20 (0.1466s) ][ GZIP on - Debug on ]