>>> This is a definitely a client-centric view!  From my server-centric
view
>>> I think the primary benefit is the elimination of the server processing
to
>>> generate and download the whole activeset metadata.

To some extent this is true but the point I was trying to make was that
building the local list of objects
by scanning the entire local filesystem has proven to be a much bigger
performance bottleneck than
building the list of server objects.

This is especially true with very large filesystems because the scan
processing becomes progressively
slower (maybe not quite exponential) with larger (number of objects) and
more complex (deeply nested dir structure)
filesystems.

The basic difference between traditional incremental backup and journal
based backup is that traditional
incremental must build three lists of objects: a local list obtained by
scanning the local filesystem, a server
list of active objects obtained over the network, and a candidate list of
objects to be updated, backed up,
or expired which is derived by comparing the local and server lists.

Journal Based Backup obtains objects to backup or expire (update currently
isn't supported) by querying
a local change journal database which is maintained by real-time monitoring
of filesystem change activity.

Journal Based Backup eliminates scanning the local filesystem, querying the
server, comparing local
and server objects, and is much less memory intensive (not only are the
local and server lists eliminated,
but the candidate list is as well because journal entries are processed
individually, i.e the entire journal
doesn't have to be stored in memory).

The disadvantage of Jbb is that it is not as comprehensive as traditional
incremental in that in can
not enforce nor detect changes in many policy attributes such as copy
frequency, binding to a
different management class, etc.

So  you can draw your own conclusions as to what types of environments it
is beneficial in ...


Pete Tanenhaus
Tivoli Storage Solutions Software Development
email: tanenhau AT us.ibm DOT com
tieline: 320.8778, external: 607.754.4213

"Those who refuse to challenge authority are condemned to conform to it"

---------------------- Forwarded by Pete Tanenhaus/San Jose/IBM on
01/11/2002 11:38 AM ---------------------------
01/11/2002 11:38 AM ---------------------------

Bill Colwell <bcolwell AT DRAPER DOT COM>@VM.MARIST.EDU> on 01/10/2002 03:47:55 
PM

Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

Sent by:    "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To:    ADSM-L AT VM.MARIST DOT EDU
cc:
Subject:    Re: ***The JOURNALED BACKUP saga continues...***



In <OFD81E2B2B.573B955C-ON85256B3D.006DC3E1 AT pok.ibm DOT com>, on 01/10/02
   at 03:47 PM, Pete Tanenhaus <tanenhau AT US.IBM DOT COM> said:

>Answers/Comments to questions......

<snip>

>The primary performance benefit over normal incremental backup is
>eliminating
>scanning the entire local file system.

This is a definitely a client-centric view!  From my server-centric view
I think the primary benefit is the elimiation of the server processing to
generate and download the whole activeset metadata.

I am planning to roll out 4.2.1.15 clients on new xp machines, implementing
both journalling and subfile backups at the same time, and to upgrade
500+ win2k machines to this level.

These are all desktop machines, not the kind of machines so far described
as the ideal candidates for journalling, but I am focusing on the server
savings.  (My server is tsm 4.2.1.7 on os/390 2.10).


--
--------------------------
--------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
--------------------------
=========================================================================