-----Original Message-----
I may soon become a fan of static files if this kind of thing keeps up.
Here is the output that you are referring to.
Dynamic Files:
Slot # Inode Device Ref Count Htype Split Merge Curmod Basemod
Largerec Filesp Selects Nextsplit
0 1900545 59425 1 20 80 50 2 2
1628 2344 0 1
1 1835009 59425 110 20 80 50 1943 1024
1628 3223064 0 920
[snip]
Based on the above it looks like a fair amount of file sizing is in
order.
Anthony
--------------------------
For starters, I disagree with Dan, whom I respect greatly, about dynamic
files. He admits to hating them, I'm partial to them, but I do not use
them indiscriminately. (in MY opinion; Dan would say I overuse them.)
That said:
Curmod being different from Basemod (analyze.shm -d columns) does not
imply needing a resize. The Basemod is just the next power of 2 below
the current modulus. It is used by the split/merge algorithm to figure
out what group to split or merge next. If Basemod is different from
Curmod, that simply means that the current modulus is not a power of 2.
If you do resize a dynamic file, you should think about the
minimum.modulus parameter. For example, resizing them with the
minimum.modulus set to what the current modulus is would pre-allocate
enough _contiguous_ space to house the current data in DATA.30. There
is no way for resize to pre-allocate contiguous space in OVER.30. If
you let minimum.modulus default to 1, then you will get repeated splits
as the file grows, and that space could be all over the disk. In a
modern RAID environment, I'm not so sure that matters.
Another approach would be to use a unix cp or mv, or dos copy. I
*think* (someone correct me, please!) that the OS looks for enough
contiguous space to hold the entire file when deciding where to put it.
cds
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
