>> On Fri, 13 Jul 2007 16:21:15 -0400, "Schaub, Steve" <steve_schaub AT BCBST 
>> DOT COM> said:


> Thanks, I did notice that little "feature".  For us, I hope it means
> we simply have to increase our versioning by one for files under HSM
> influence.

Not unless you're planning on doing retextra=nolimit.  And further,
since you have to keep the archives forever, you'll end up with N
versions of the (identical) file archived, where N is the number of
times the file has been retrieved.

> One question I have not been able to figure out is whether HSM & the
> filesystem ever perform any sort of "reconciliation" - for example,
> when a user finally decides to delete his illegal mp3 collection
> from the corporate fileserver, how does the HSM archive receive that
> notice so it can be reclaimed?  Or are we going to have ghosts in
> the attic forever?

The latter.  The archives have to be kept forever, unless you want the
"real" files for which you've got stubs to softly and silently vanish
away.

> Unfortunately, it may be our only hope to extend the life of some
> fileservers, given that we are not able to enforce any sort of user
> quotas (don't even get me started).

Not just no, but hell no.

If you're visualizing this as an inexpensive way to stretch the
capacity of a more or less normal fileserver, prefer just pouring
bleach in your eyes.  The HSM for windows developer even specified
that it was only appropriate for extremely stable, extremely large
installations.

Think a static output directory for your ERP system to stick reports
whicn we all know nobody will ever read, but some sort of beuracratic
peristalysis demands N-year retention.

Please, please please don't use this for anything approaching a
conventional fileserver.

For that application, far better to put up SAMBA in front of an AIX
filesystem that uses something a real HSM, or better yet just buy some
multi-TB nas-in-a-box.


- Allen S. Rout