AROUND the WORLD... Technology for Sun Partners

Introduction to the Business Problem

More and more software applications have to meet storage compliance reagulations. This means that they have to warrant that data is going to preserved for a given period of time. Regional legislation across the world forces software vendors to comply with various archiving periods.
To keep a long story short: More and more files need to be kept and to be retrieved upon request.
Even worse: Operators of a software system have to be able to demonstrate that they took precaution in keping the data.
Document archieving vendors are the ISVs who are most advanced in managing this aspect of meeting compliance requirements. Sun is working closely with them by providing operating system and file system support to meet advisory and strict compliance requirements.
Sun WORM-FS and the Sun NAS filer family have APIs to support these extended requirements.

A File with a normal Life Cycle

A conventional application is typically moving a file through three different states
  • It creates a file.
  • It modifies a file
  • It deletes a file
The diagram below shows the different states of this life cycle.

A WORM Life Cycle with Retention Period

An application managing files which have be retrieved within a warranted period without any modification need to satisfy a more complex file life cycle. They have to support the following additional states
  • make a file read only (WORM: Write Once, Read Multiple) for the rest of the life time.
  • set a retention period for a WORM file. The file may not be deleted within this period
  • expired retention state. The rentention period is expired. A new retention period may be defined or the file can be deleted otherwise.
The diagram below shows the state transition of a "WORM" enabled file:

That much about the theory of file states...
The interesting aspect for an application developer is that operating system features can be used to assure that files become permanently immutable.

Implementing the WORM-FS Functionality

An application can use the WORM features by:
  • Performing a chmod operation with the pattern 4000 on the directory
  • Performing a chmod operation with the pattern 4000 on the file in question.
The file is now a WORM file with the default retention period inherited by the directory.
The remaining (optional) step is to define an individual retention period by using the afile attribute of a file. This can be done as follows:
$ touch -a -t20170217 stefansRetirementFile

This is what it takes from the application development side! The remaining task is to provide a file system infrastructure.

Infrastructure required

The examples shown above will work for any Unix (and Linux) client which can access a Sun SAM-FS server or NAS filer through NFS or locally. Windows clients can be served as well.
The Sun NAS filer family supports this feature since NAS-OS 4.12. It just takes a number of clicks on the web interface to enable a volume on the NAS filer to be a volume with WORM features.
The same feature is available within SAM-FS 4 update 3 (or higher) the hierachical archive file systems which supports complex disk and tape landsape.
The programing API is identical for both product families

Access to Resources

This write up was just drawing the big picture. Good follow up resources are the following ones:

The End

I hope that this very brief overview is going to be helpful. The programming API is extremely simple. The effects are significant. Software will meet compliance requirements. Applications become more reliable. Setting a WORM trigger will protect as well files against accidental deleion by system operators. The API is getting adopted by a number of Sun partners. The latest adoption is for example Open Text's LiveLink ECM Archiving Suites which support this API starting with LEA 9.6.
Comments:

Post a Comment:
  • HTML Syntax: NOT allowed