>> On Mon, 28 Jan 2008 15:14:26 -0500, Curtis Preston <cpreston AT GLASSHOUSE
>> DOT COM> said:
> Your "pedantic" (to use your word) response was actually quite helpful.
> I knew about aggregates, but did NOT know that they were only tracked in
> the database at the aggregate level.
It's been made clear to me that I've been inadequately precise,
despite my best efforts at pedantry; You all have my abject apologies,
I am ony an egg.
Every file certainly does have a database entry: that's how individual
files can be expired, and aggregates eventually "reconstructued".
(i.e. move data reconstruct=yes, or in space reclamation)
I think that the point I failed to make clearly was that the
aggregates form an abstraction layer _between_ "Where is a file
logically", and "where is a file physically". I'm told this is
analogous to an MVS "block", but don't have the clue myself to
elaborate on that analogy.
So, say a given file ('foo.doc') is logically located in aggregate
737828937362, offset 2217 bytes; It is the aggregate which is the unit
of address when you COPY STG or MIGRATE STG. It is the aggregate
which in turn has a physical location, (I'm on volser T00374, 450GB in
at file marker 7473). So we can calculate that foo.doc is on T00374,
at 450G + 2217 bytes, but we have to go through the intermediate step.
This means that the objects table has N rows where N=object count, but
the storage mapping tables can be much smaller. It appears that
TXNGROUPMAX and TXNBYTELIMIT serve as caps to this, so it could be as
much as N/65000 , which would be silly. N/100 to N/50 is probably
reasonable.
And this efficiency is reflected in all of your COPY STGPOOL
behaviors, which we do daily, repeatedly.
There may be degenerate cases of large files where the aggregate
abstraction layer is ommited, but we don't really care about those in
this case.
Because of this double-indirection, it is straightforward to _add_ an
_additional_ copy with some semantic tweaking (i.e. make another
copy, but only pay attention to active data)
But to _change_ the _existing_ aggregate (by migrating out the
inactive data) will cause confusion in all the copies and migrations
which have already happened, and will generate new aggregates which
must then be maintained.
And if I've hashed this up yet again, I'll just sit the *bleep* down
and try to get a developer to talk about it.
- Allen S. Rout
|
