On Aug 26,  5:02pm, Stan Sieler wrote:
> AFAIK, the JFS is like what XM would be if you restricted it to *only*
> working for file system data structures (i.e., no user data).
>
> MPE uses XM to protect the file structures, *and* (optionally) user data.
> (IMAGE and KSAM/iX and "serial write queue (see fcontrol)" files
> are examples of XM protected user data)
>
> I don't believe that JFS provides for user-data coverage.
>-- End of excerpt from Stan Sieler


I haven't had much direct experience with JFS, as part of a temporary
assignment I once helped resolve a bug report that involved JFS (HP-UX's
Journaled File System) and LVM (Logical Volume Management - what we get for
free with MPE volume sets). Coming from a pure MPE file system background it
was... hmmm... *interesting* to see some of the inner workings of HP-UX... but
that's another story.

What little I did learn is identical to what Stan reported. JFS is used to
journal changes to file metadata only. In MPE terms this would mean that only
the system data structures used to manage the files, volumes and volume sets
are protected. No user data is journaled. Part of the reason for this is that
JFS only provides logical logging and recovery, not physical logging as MPE's
XM does.

To illustrate the difference (very simplistically and probably somewhat
inaccurately :-) ) a change to the access timestamp of a file would be logged
in JFS something like:

  .
  .
  .
 utime (file, '8-26-1998 5:50PM')
  .
  .
  .

The change is logged as the logical information that changed; in this case I've
shown it as the Unix function that allows file timestamps to be modified. In
contrast, on MPE/iX, the Transaction Manager (XM) would log the change as:

   .
   .
   .
 file : before image : address 11.abcdef12 : value 01234567 89abcdef
 file : after image  : address 11.abcdef12 : value abadcad2 deaf2cee
 file : commit change
   .
   .
   .

In the XM case we log the address of the data, and then the physical data
itself. When recovering after a system failure, if the transaction was not
committed, then the before image is applied to make sure that we clean up for
any transient state that the file might have been in. If the transaction was
committed, then the after image is applied.

I believe the reason that JFS does not allow for user data is because it uses
logical logging instead of logging the physical changes to the user's data, as
XM does.

In terms of overhead differences, there is probably very little difference when
apples can be compared with apples. Logical logging (JFS) is advantageous
because it allows complex transactions to be logged with a brief "shorthand."
However, XM has been tuned to log only the pieces of data that have actually
changed; in the example above just the timestamp value itself was logged, not
the entire file label. Of course, when logging user data XM will take longer,
depending on the amount of data involved in each transaction. JFS does not
support this feature, so it cannot be compared.

I hope this helps!

Craig

--
Craig Fairchild

Email: [log in to unmask]               Phone: (408) 447-5990
USPS:  Hewlett-Packard Company           Fax:   (408) 447-4278
       M/S 47UA
       19447 Pruneridge Avenue
       Cupertino, CA 95014