>> On Mon, 28 Jan 2008 15:14:26 -0500, Curtis Preston <[EMAIL PROTECTED]> 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