CLUSTER_SIZE ramification
Keith A. Lewis
on new 72GB spindles.
I will be able to estimate in advance roughly how many files on each disk.
Based on that, what should my cluster size be?
Assuming random file sizes, you "waste" half of a cluster per file, on
average. So I want to set it low. But I have noticed that large disks with
cluster size = 1 have huge INDEXF.SYS files, and that's no good either. For
example, I have a 36GB drive with a 1.25GB INDEXF file.
Is there a formula to calculate how big the INDEXF file will be based on
disk size and cluster size?
--Keith Lewis klewis {at} mitre.org
The above may not (yet) represent the opinions of my employer.
John Laird
Lewis) wrote:
>I'm going to consolidate a dozen or so ODS-2/5 volumes into just 4 new ones,
>on new 72GB spindles.
>
>I will be able to estimate in advance roughly how many files on each disk.
>Based on that, what should my cluster size be?
>
>Assuming random file sizes, you "waste" half of a cluster per file, on
>average. So I want to set it low. But I have noticed that large disks with
>cluster size = 1 have huge INDEXF.SYS files, and that's no good either. For
>example, I have a 36GB drive with a 1.25GB INDEXF file.
>
>Is there a formula to calculate how big the INDEXF file will be based on
>disk size and cluster size?
See the online help for INITIALIZE. INDEXF.SYS is nearly all headers, so it
is sized according to the actual number of files and constrained by the
maximum number of files on the volume. This is limited to
disk-size-in-blocks/(cluster-size+1) and defaults to half that value.
However, INDEXF.SYS grows dynamically and can start very small, but you can
pre-allocate space with the /HEADERS qualifier, and fix the maximum size
with /MAXIMUM_FILES.
I would say you probably don't want to waste more than 10% of the disk with
partly-filled clusters, and that in itself suggests a cluster size of 1/5th
the average file size. Only you know what that is. Or rather you suggest
you know how many files you need, from which you can work out a sensible
cluster factor. The overhead in BITMAP.SYS is only 1 bit per cluster,
whereas in INDEXF.SYS it is 2048 bits per file.
Do you really have up to 2.5 million files on your 36Gb drive ?
--
We should go metric every inch of the way!
Mail john rather than nospam...
John Laird
wrote:
>The overhead in BITMAP.SYS is only 1 bit per cluster,
>whereas in INDEXF.SYS it is 2048 bits per file.
Shoot, that should have been 4096 bits of course (512 bytes x 8bits/byte).
--
Life is complex: It consists of real and imaginary parts.
Bob Kaplow
> I would say you probably don't want to waste more than 10% of the disk with
> partly-filled clusters, and that in itself suggests a cluster size of 1/5th
> the average file size. Only you know what that is. Or rather you suggest
> you know how many files you need, from which you can work out a sensible
> cluster factor. The overhead in BITMAP.SYS is only 1 bit per cluster,
> whereas in INDEXF.SYS it is 2048 bits per file.
Many years ago someone showed me a neat way to deal with this. Assuming you
have a disk with a small cluster size to begin with, Diskkeepers free
analyzer used to be able to generate a storage histogram of files by size.
From that you could look for the mode (peak of the graph), and set the
cluster size to something near that value.
Of course the existing cluster size would mask anything below that size. But
most data disks showed pretty clear preferences based on the mode.
Bob Kaplow NAR # 18L TRA # "Impeach the TRA BoD"
>>> To reply, remove the TRABoD! <<<
Kaplow Klips & Baffle: http://nira-rocketry.org/LeadingEdge/Phantom4000.pdf
www.encompasserve.org/~kaplow_r/ www.nira-rocketry.org www.nar.org
We must have faith in our democratic system and our Constitution,
and in our ability to protect at the same time both the freedom and
the security of all Americans.
Carl Karcher
->
-> [Some very good points]
->
->...Do you really have up to 2.5 million files on your 36Gb drive ?
If you plan to use expandable volumes (INIT/LIMIT=n) some day,
then possibly.
--
-- Carl Karcher, Waisman Computing Services, Waisman Center, UW-Madison
-- karcher.n...@waisman.wisc.edu
Keith A. Lewis
>On Tue, 30 Nov 2004 23:21:40 +0000 (UTC), le...@SPYDER.MITRE.ORG (Keith A.
>Lewis) wrote:
>>
>>Assuming random file sizes, you "waste" half of a cluster per file, on
>>average. So I want to set it low. But I have noticed that large disks with
>>cluster size = 1 have huge INDEXF.SYS files, and that's no good either. For
>>example, I have a 36GB drive with a 1.25GB INDEXF file.
>>
>>Is there a formula to calculate how big the INDEXF file will be based on
>>disk size and cluster size?
>
>See the online help for INITIALIZE. INDEXF.SYS is nearly all headers, so it
>is sized according to the actual number of files and constrained by the
>maximum number of files on the volume. This is limited to
>disk-size-in-blocks/(cluster-size+1) and defaults to half that value.
>However, INDEXF.SYS grows dynamically and can start very small, but you can
>pre-allocate space with the /HEADERS qualifier, and fix the maximum size
>with /MAXIMUM_FILES.
>Do you really have up to 2.5 million files on your 36Gb drive ?
I seriously doubt it. It's currently at 16,867 files and 95% full, the disk
is used for application data which are not small files. I'd be willing to
bet it has never gone over 100,000 files at the same time on that volume,
although the historic total could be 2.5M if you count every file that has
ever been stored there.
I probably initialized it with a relatively vanilla INIT command 4 years
ago, something like:
$ INIT $12$DKB500 DATA6A /OWN=SYSTEM /CLUSTER=1/NOHIGH
Since then we've been running ANAL/DISK/REPAIR every week as well as DFO.
Does one of those add to INDEXF?
John Laird
Lewis) wrote:
>John Laird <nos...@laird-towers.org.uk> writes in article <5f0qq0h1c3t4i97bn...@4ax.com> dated Tue, 30 Nov 2004 23:38:22 +0000:
>>
>>Do you really have up to 2.5 million files on your 36Gb drive ?
>
>I seriously doubt it. It's currently at 16,867 files and 95% full, the disk
>is used for application data which are not small files. I'd be willing to
>bet it has never gone over 100,000 files at the same time on that volume,
>although the historic total could be 2.5M if you count every file that has
>ever been stored there.
Headers are re-used, as you probably guessed or knew. Although you have set
a minimum cluster size (below) I am more than a little surprised that
*something* has made INDEXF.SYS so big. The formula says that the absolute
maximum number of files is going to be 36 million, however (disk size in
blocks / cluster_factor+1). It is possible therefore that on some extend,
the file has been made equal to some percentage of the maximum - this would
prevent disasters when the index file cannot be extended at all because it
itself must be mapped within one retrieval pointer and therefore has a
maximum number of permitted fragments. Anyone who has suffered this in the
past when disk got init'd with an indexf.sys of 16 blocks and grew too
gradually will remember the pain of that scenario.
>I probably initialized it with a relatively vanilla INIT command 4 years
>ago, something like:
>
> $ INIT $12$DKB500 DATA6A /OWN=SYSTEM /CLUSTER=1/NOHIGH
>
>Since then we've been running ANAL/DISK/REPAIR every week as well as DFO.
>Does one of those add to INDEXF?
I would hope not, but that's just a supposition. I think if you wish to use
/CLUSTER=1 (and to be honest that's too small looking at your file numbers),
then you should also set /MAXIMUM_FILES to a much more realistic value.
Even something like 200000 (ten times your current use) will only yield an
index file of that size plus a little bit, which is quite workable, and I
might further guess that it will never actually reach that size.
--
Never let people drive you crazy when it's within walking distance.
Keith A. Lewis
>On Wed, 1 Dec 2004 16:27:23 +0000 (UTC), le...@SPYDER.MITRE.ORG (Keith A.
>Lewis) wrote:
>
>>John Laird <nos...@laird-towers.org.uk> writes in article <5f0qq0h1c3t4i97bn...@4ax.com> dated Tue, 30 Nov 2004 23:38:22 +0000:
>>>
>>>Do you really have up to 2.5 million files on your 36Gb drive ?
Thanks for all your help, John.
Here's another data point, from a different drive. Also 36GB with a cluster
size of 1. INDEXF has an allocation size which exactly matches the other
disk, but a much more reasonable used size.
If anybody can explain how this happened, I'm listening. Also, is it safe
to do a SET FILE/TRUNC on INDEXF?
$ dir/size=all $5$DKA500:[000000]indexf
Directory $5$DKA500:[000000]
INDEXF.SYS;1 15100/2510849
Total of 1 file, 15100/2510849 blocks.
$ sho dev/full $5$DKA500:
Disk $5$DKA500: (LUMINA), device type COMPAQ BA03611C9B, is online, mounted,
file-oriented device, shareable, available to cluster, error logging is
enabled.
Error count 0 Operations completed 4092
Owner process "" Owner UIC [SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:R,W
Reference count 1 Default buffer size 512
Total blocks 71132000 Sectors per track 254
Total cylinders 14003 Tracks per cylinder 20
Host name "LUMINA" Host type, avail COMPAQ AlphaServer DS20
E 666 MHz, yes
Allocation class 5
Volume label "DATA4" Relative volume number 0
Cluster size 1 Transaction count 1
Free blocks 2710889 Maximum files allowed 16711679
Extend quantity 5 Mount count 5
Mount status System Cache name "_DSA0:XQPCACHE"
Extent cache size 64 Maximum blocks in extent cache 271088
File ID cache size 64 Blocks in extent cache 0
Quota cache size 0 Maximum buffers in FCP cache 2594
Volume owner UIC [SYSTEM] Vol Prot S:RWCD,O:RWCD,G:RWCD,W:RWCD
Volume Status: ODS-2, subject to mount verification, write-back caching
enabled.
Volume is also mounted on LUMINA, OMEGA, PROBE, BOXTER.
John Laird
Lewis) wrote:
>Here's another data point, from a different drive. Also 36GB with a cluster
>size of 1. INDEXF has an allocation size which exactly matches the other
>disk, but a much more reasonable used size.
Curious indeed. I am sure that /HEADERS will set the initial allocation (as
documented), and as I (nearly) always remember to use this, it is probable
that I have never noticed the extend behaviour on a disk with a much smaller
initial allocation and not such a large maximum number of files that results
from your choice of a very small cluster factor. Then again, cluster size
pre 7.x (I forget which) defaults to no more than roughly 1 million
clusters, thus half a million files, and it is possible that an algorithm
which sets some early extend out to maybe 10% of the max would go more
unnoticed (it's only 50000 blocks).
>If anybody can explain how this happened, I'm listening. Also, is it safe
>to do a SET FILE/TRUNC on INDEXF?
It may or may not work - INDEXF.SYS being a special file and permanently
open while a disk is mounted - but one would hope that if it damaged
anything, someone might have noticed by now !
--
Don't play stupid with me... I'm better at it!
Alan E. Feldman
> John Laird <nos...@laird-towers.org.uk> writes in article <u1vrq01gr6q4mkpo9...@4ax.com> dated Wed, 01 Dec 2004 17:38:42 +0000:
> >On Wed, 1 Dec 2004 16:27:23 +0000 (UTC), le...@SPYDER.MITRE.ORG (Keith A.
> >Lewis) wrote:
> >
> >>John Laird <nos...@laird-towers.org.uk> writes in article <5f0qq0h1c3t4i97bn...@4ax.com> dated Tue, 30 Nov 2004 23:38:22 +0000:
> >>>
> >>>Do you really have up to 2.5 million files on your 36Gb drive ?
>
> Thanks for all your help, John.
>
> Here's another data point, from a different drive. Also 36GB with a cluster
> size of 1. INDEXF has an allocation size which exactly matches the other
> disk, but a much more reasonable used size.
>
> If anybody can explain how this happened, I'm listening.
Explanation at bottom.
> Also, is it safe
> to do a SET FILE/TRUNC on INDEXF?
I never tried it, but I think it would be safe. HOWEVER, I think that
as soon as you need another extension of INDEXF.SYS you will get a
simiarly big INDEXF.SYS again! See the explanation at the bottom.
> $ dir/size=all $5$DKA500:[000000]indexf
>
> Directory $5$DKA500:[000000]
>
> INDEXF.SYS;1 15100/2510849
>
> Total of 1 file, 15100/2510849 blocks.
> $ sho dev/full $5$DKA500:
>
> Disk $5$DKA500: (LUMINA), device type COMPAQ BA03611C9B, is online, mounted,
> file-oriented device, shareable, available to cluster, error logging is
> enabled.
>
> Error count 0 Operations completed 4092
> Owner process "" Owner UIC [SYSTEM]
> Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:R,W
> Reference count 1 Default buffer size 512
> Total blocks 71132000 Sectors per track 254
> Total cylinders 14003 Tracks per cylinder 20
> Host name "LUMINA" Host type, avail COMPAQ AlphaServer DS20
> E 666 MHz, yes
> Allocation class 5
>
> Volume label "DATA4" Relative volume number 0
> Cluster size 1 Transaction count 1
> Free blocks 2710889 Maximum files allowed 16711679
[...]
I believe this is due to the "new" (well, new as of VMS v6.0)
extension algorithm for INDEXF.SYS.
I quote from:
http://ftp.support.compaq.com.au/pub/patches/vms/vax/v6.0/vaxf11x03_070.README
o Disk space is inefficiently used due to the default extension
size of INDEXF.SYS. The algorithm now tries to extend the
file by 15% of MAX_FILES - HEADERS_USED. It does this until
the index file has grown to 90% of MAX_FILES. From then on
the file is extended in increments of 1% of MAX_FILES.
This problem is fixed in OpenVMS VAX V6.0.
CSC NOTE: This problem may also occur on OpenVMS Alpha V6.1.
The AXPF11X02_061 ECO kit will fix the problem on
OpenVMS Alpha V6.1.
So,
Maximum files from above = 16711679
times .15 = 2506751.
Size of your indexf.sys = 2510849
which is close enough. I neglected to subtract the number of used
headers. Also, the total size of INDEXF.SYS would be the initial size
plus the expansion. So I think this is the explanation.
Three ways to avoid this in the future:
1.) Give a value for the /MAXIMUM_FILES qualifier. But make sure it is
not too low. You cannot have more file headers on the disk than you
specify for this qualifier without re-INIT-ing the disk (unless
there's some tool I am unaware of that can acutally do this, and if
there were such a tool, I'd expect you'd need exclusive access to the
disk).
2.) Just overestimate the maximum number of files (actually file
headers) you'll ever have on the disk and use this number for the
/HEADERS qualifier. Be generous in your overestimate. Having more file
headers than this number will cause an expansion.
3.) Use a larger cluster size. Do you really need it to be 1?
BTW, this is a much better problem to have than the dreaded HEADERFUL
error which is what happens when the file header for INDEXF.SYS runs
out of room due to too many small extensions!
John Laird
wrote:
>John Laird <nos...@laird-towers.org.uk> wrote in message news:<algsq0d3ustvsdq2u...@4ax.com>...
>> On Wed, 1 Dec 2004 19:39:49 +0000 (UTC), le...@SPYDER.MITRE.ORG (Keith A.
>> Lewis) wrote:
>>
>[...]
>
>> >Also, is it safe
>> >to do a SET FILE/TRUNC on INDEXF?
>>
>> It may or may not work - INDEXF.SYS being a special file and permanently
>> open while a disk is mounted - but one would hope that if it damaged
>> anything, someone might have noticed by now !
>
>It doesn't work because the file is open. You get an error --
>-SYSTEM-W-ACCONFLICT -- when you try. So it's safe, but it doesn't
>work. ;-)
I rather suspected that would be the case. A dig around in the help for DFU
didn't reveal any magic way to achieve this in there either. A backup and
restore (with manual init) is probably the easiest route(*), but only
worthwhile if the lost space is significant. The unused allocation is not
doing any harm.
(*) Mount/foreign and a block-level patch utility is also an option. But
I'd carefully check the structure of indexf.sys itself in case it internally
knows how big it is supposed to be, before zapping its header and running an
anal/disk/repair to recover the "incorrectly allocated" blocks.
--
I'm a disfunctional husband of a BBS widow.
Alan E. Feldman
> >Also, is it safe
> >to do a SET FILE/TRUNC on INDEXF?
>
> It may or may not work - INDEXF.SYS being a special file and permanently
> open while a disk is mounted - but one would hope that if it damaged
> anything, someone might have noticed by now !
It doesn't work because the file is open. You get an error --
Carl Karcher
->>It doesn't work because the file is open. You get an error --
->>-SYSTEM-W-ACCONFLICT -- when you try. So it's safe, but it doesn't
->>work. ;-)
->
->I rather suspected that would be the case. A dig around in the help for DFU
->didn't reveal any magic way to achieve this in there either. A backup and
->restore (with manual init) is probably the easiest route(*), but only
->worthwhile if the lost space is significant. The unused allocation is not
->doing any harm.
If you have DFO (Defrag) you might try dismounting the disk followed by
"DEFRAGMENT OFFLINE_VOLUME <disk>". That will defragment the indexf.sys
file but I don't know whether it will truncate the unused space as well.