| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 9452.1 | | DECWET::MARTIN | | Wed Apr 09 1997 17:04 | 16 |
| The "missing" space is called metadata. It's the data that's used by AdvFS to
translate logical disk blocks into physical disk blocks.
This data doesn't show up in 'df' because this is per-domain data, not
per-fileset data. Running 'showfdmn' and 'showfsets' will show you more
information than 'df'.
The -p flag of 28800 pre-allocates 28800 pages to this metadata (the BMT
specifically), which is 460800 blocks. If there is over 2.25 gigs of small
files, the BMT will probably require quite a bit more space than this to keep
track of where everything is.
See DECWET::ADVFS_SUPPORT note 187.x (I think that's the FAQ note) for more
detail.
--Ken
|
| 9452.2 | reply to .1 | MLNCSC::ZAGHI | | Thu Apr 10 1997 04:39 | 11 |
| Hi ken,
By means of your helpfull reply I can better explain to the customer
the cause of his "missing space".
Many thanks too
Regards
Paolo
(CSC , Milan)
|
| 9452.3 | 2.5 Gb / 400,000 = 6710 bytes | BRSSWS::DEVOS | Manu Devos DEC/SI Brussels 856-7539 | Thu Apr 10 1997 12:48 | 19 |
| Hi Ken,
>> The -p flag of 28800 pre-allocates 28800 pages to this metadata (the
>> BMT specifically), which is 460800 blocks. If there is over 2.25 gigs
>> of small files, the BMT will probably require quite a bit more space
>> than this to keep track of where everything is.
The mkfdmn(8) and addvol(8) of D.U. V4.0B are saying :
Number of files Extent Size (pages) Metadata table size (pages)
... ... ...
400,000 1024 28,800
How did you come from 400,000 files to 2,5 gigs of small files ?
Is a small file definition saying it is 6710 bytes ?
Manu.
|
| 9452.4 | not enought info to make anything be a guess | UNIFIX::HARRIS | Juggling has its ups and downs | Thu Apr 10 1997 15:37 | 85 |
| re: .3
> How did you come from 400,000 files to 2,5 gigs of small files ?
I don't think Ken was saying anything about the number of files or
about the -p 28800 initial value. Ken made the obversation that the
disk was using approx 2.5G of space and it was very likely that
additional metadata space was allocated along the way. Some of it is
in the Log file, some in the bitmap, some in the tag directory, and a
lot of it in the BMT.
> Is a small file definition saying it is 6710 bytes ?
The minimum amount of space allocated to a file is 1K, so it is
possible to have lots of 1K files in 2.5G.
Also we do not know what this file system has been used for. If it was
cloned and the clone left around for a long time while more and more
changes were made, causing the clone to absorbe more and more metadata
space to map the old.
All in all, I don't think we have nearly enough information about this
specific system to say where all the space is located.
----
Attached is a very rude and crude script that will calculate the amount
of metadata space being used by the AdvFS file system. One of the
reasons it is rude and crude is that it doesn't attempt to figure out
how much space is tied up in frags, and I'm not 100% sure I caught all
the places metadata is stored. And while I tried to do some error
checking, it is far from being air tight.
Bob Harris
#!/bin/sh
#
domain=$1
mount_point=$2
#
usage() {
echo "Usage: showAdvfsMetaSize domain_name /fileset_mount_point" 1>&2
echo "" 1>&2
echo " This is a rude and crude script to make a quick estimate" 1>&2
echo " of how much space is being taken up by AdvFS metadata" 1>&2
echo " files for the specified domain." 1>&2
exit 1
}
if [ $# -ne 2 ]
then
usage
fi
if [ ! -d $mount_point/.tags ]
then
usage
fi
cd $mount_point/.tags
sizek=0
sizeb=0
vols=`/sbin/showfdmn $domain | awk '
NF == 8 {
if ( length($1) <= 3 ) {
sub("L"," ",$1)
if ( $1 < 256 )
print $1
}
}
'`
for j in $vols
do
for k in 0 1 2 3 4 5
do
m=`expr $k + \( $j \* 6 \)`
n=`if ls -ls M-$m 2>/dev/null; then a=0; else echo 0; fi`
set - $n
sizek=`expr $sizek + $1`
if [ $# -gt 6 ]
then
sizeb=`expr $sizeb + $6`
fi
done
done
echo "Domain $domain is using approximately ${sizek}K (${sizeb} bytes) for metadata"
|