Introduction to SAM and QFS

 

URLS: (for any of Sun’s documentation, go to docs.sun.com and search for QFS)

Mary Ann Lynch: SAM-FS and QFS web page – main web page

http://lists.ee.ethz.ch/sam-managers - The SAM managers list-serv archive

Sun StorageTek QFS File System Configuration and Administration Guide, Version 4, Update 6

Sun StorageTek Storage Archive Manager (SAM) File System Configuration and Administration Guide, Version 4, Update 6

Sun StorageTek QFS Installation and Upgrade Guide, Version 4, Update 6

Sun StorageTek Storage Archive Manager (SAM) Installation and Upgrade Guide, Version 4, Update 6

Sun StorageTek QFS and Storage Archive Manager (SAM) Release Notes, Version 4, Update 6

Sun StorageTek Storage Archive Manager (SAM) Archive Configuration and Administration Guide, Version 4, Update 6

Sun StorageTek Storage Archive Manager (SAM) Troubleshooting Guide, Version 4, Update 6

File System Manager User's Guide v 3.0

Sun StorEdge QFS, Sun StorEdge SAM-FS, and Sun StorEdge SAM-QFS Disaster Recovery Guide

Sun StorageTek QFS Linux Client Guide, Version 4, Update 6

Selim Daoud’s Clustering SAM-QFS examples

http://opensolaris.org/os/project/samqfs/ - The SAM-QFS discussion alias

http://wikis.sun.com/display/SAMQFS/Home - The SAM-QFS wiki

 

Introduction

 

These documents cover the software contained in the Sun® Microsystems Inc. products Sun StorageTek® Storage Archive Manager (SAM) 4.4 to 4.6 and Sun StorageTek QFS 4.4 to 4.6. These products were called Sun StorEdge SAM-FS and Sun StorEdge QFS in previous releases, and these names sometimes still appear in documentation used for later releases. For simplicity, Release 4.6 will be referenced in these documents, and, unless noted, all comments applicable to Release 4.6 will also apply to Releases 4.4 and 4.5.

 

These products contain the software necessary to install a basic disk-based file system (FS), a high performance version of that file system (QFS) and a hierarchical storage manager (SAM).

 

The Software: The names change, the software does not

 

Sun StorageTek SAM software consists of the packages SUNWsamfsr and SUNWsamfsu, which include archiving software (SAM) and a file system that can be set up to work as either a basic file system (FS) or a high-performance file system (QFS). It is the equivalent of Sun StorEdge Utilization Suite and of Sun StorEdge SAM-FS which provided the same functionality for previous releases of the software.

 

The product Sun StorageTek QFS is the equivalent of Sun StorEdge Performance Suite and Sun StorEdge QFS. It consists of the packages SUNWqfsr and SUNWqfsu. When these packages are installed, only the high performance file system, QFS, can be configured. The SAM software is not installed. The Sun StorageTek QFS product allows you to install a QFS file system without having to put archiving software on the system. It might be installed if you want to install Oracle RAC on a high performance file system, but don’t want to archive, or if you want to set up a SAM-QFS shared file system client. Almost all the software in the Sun StorageTek QFS product is included in Sun StorageTek SAM, so only one of Sun StorageTek SAM and Sun StorageTek QFS can be installed on one host. If you want a high performance file system with archiving, install the “SAM” product. You do not need to also install the QFS product.

 

 

 

 

The administrator can configure just one file system on a host or multiple file systems of any kind. The archiving software must be used with either the basic file system as SAM-FS or with the high-performance file system as SAM-QFS. The archiving software does not stand alone, nor can it be used to manage storage on other file systems. QFS can be used alone as a high performance file system in a Storage Area Network (SAN) environment when no archiving is required.

 

 Too Much SAM-FS

 

There are five different uses of the term “SAM-FS,” which can become confusing.

 

1. SAM-FS is the shortened name of the Sun StorEdge SAM-FS product which contained all file system and archiving software for Releases 4.1-4.5 of the product.

 

2. SAM-FS is the name of a configuration of the SAM-FS product. It consists of a basic file system and archiving software.

 

3. “SAM-FS” is used to refer to the basic disk-based file system (FS). The basic file system does not provide the performance enhancements of the high performance file system (QFS) so Sun does not support it as a standalone file system, nor does Sun recognize “FS” as legitimate terminology. When Sun’s documentation discusses the basic file system it therefore refers to it as SAM-FS, even if archiving is not under discussion.

 

4.“SAM-FS” is sometimes used to describe any archiving file system, whether it is actually the basic file system with archiving (SAM-FS), or if it is the high performance file system with archiving (SAM-QFS). Sun does not use this terminology, nor will these papers, but it is commonly used by administrators and managers working with SAM-QFS file systems, and you will see it on listservs and blog posts.

 

5. The kernel module samfs controls both the basic and the high performance file systems. This is written as a single word in small letters, unlike other uses of the term SAM-FS.

 

In Sun’s documentation, it is usually possible to tell from context which use of SAM-FS is being discussed. In conversation, Sun’s engineers and architects often refer to any archiving file system as “SAM-Q.” If you are talking to an administrator or reading an online commentary, you may have to ask for clarification.

 

Hierarchical Storage Management  - What does this software do?

 

Ideally, all files in a data center are available on disk at all times, as that offers the fastest access performance. In reality, keeping all files continuously on disk may require more disk storage than a business can afford. Generally only 15-25% of the data on a computer's disk drives is frequently used and must be stored on disk. The remainder unnecessarily uses up expensive disk storage. Most of the data stored on disk in the typical computing environment is also backed up even when it has not changed since the last backup. Businesses that produce very large amounts of infrequently used data might therefore store and repeatedly back up unchanged data at great cost and inconvenience.

 

These problems can be addressed with hierarchical storage management software. This software stores data in different types of media based on priorities set up by the system administrator. All files are copied to an online library of removable media, after which frequently used files may be left on the system disk. Files not modified in a specified period of time may be removed from the disk or "released". Released files can later be retrieved from the media library after a short delay. Media containing long-unused files may be removed from the media library and stored.

 

Storage and Archive Manager (SAM) Overview

 

The following section provides a brief, superficial overview of the function of the storage and archiving manager. It introduces the terminology and concepts of hierarchical storage management as they are implemented in Sun’s products. Each of these topics will be discussed in more depth elsewhere.

 

SAM software performs three fundamental processes on files in SAM-QFS or SAM-FS file systems:

Archiving

Releasing

Staging

 

SAM-FS or SAM-QFS allows the administrator to profile the data stored in a SAM-FS or SAM-QFS file system based on the data's location in the directory tree, size, and other parameters. The profile is used to send one or more copies of files to tape or magneto-optical disk (archiving), leaving the original file on disk. As the disk fills up, archived files may be removed entirely or partially from the file system on disk (releasing), making room for more files. If a released file is accessed, it can be moved automatically back to disk (staging) from archive media. While resident on disk, the staged file can be read and modified. An archive copy may be marked by the administrator or by SAM processes for movement to another location. This is called rearchiving, and is performed by the archiving daemons. It is not a separate process.

 

Archive Copy Lifecycle - Archive Copy States

 

An archive copy may be in one of three states:

 

current - it is the same as the file on disk, and its location is known to the file system.

stale - it is not the same as the file on disk, but its location is known to the file system. This is a transient state.

expired (also called “obsolete) - it is unknown to the file system.

 

When a file is created, any archive copies made contain the same data as the file on disk. The location of these archive copies is written into the inode of the file on disk. Such an archive copy is “current” which means 1) it is the same as the file on disk and 2) its location is known to the file system, because it is recorded in the file inode. When the file is modified, the original current archives on tape are immediately marked "stale" in the inode, that is, they no longer reflect the current state of the file. The “stale” state is transient because files with stale archive copies must be promptly archived again (this process is never called "rearchiving" - that term is reserved for the process of moving current archives to a new location). The location information of the new archive copies overwrites the location information for the stale archives in the inode, at which point the stale archives become “expired” or “obsolete,” because they are no longer recorded in file system metadata. After archiving, the file is represented on tape by two sets of archives, a current set that is known to the file system and an expired set that is unknown to the file system.

 

Archive copies of files may expire for a number of reasons. The original file may have been modified and archived again as described above. An archive copy may be rearchived to a new location, a process discussed in subsequent documents. The original file may be deleted, in which case its inode is deallocated, and the information in that inode, including archive copy information, becomes unknown to the file system. There are no labels on expired archive copies on tape indicating their state. No mark is placed on the archive media when a copy expires. They are simply not known to the file system.

 

Archive Copy Lifecycle - Recycling

 

If files are frequently modified or deleted, the media in the tape or disk library will eventually fill up with a mixture of current and obsolete (or “expired”) archives. When this happens, current archives can be moved around (rearchiving) so that some tapes are empty of current archives and contain only obsolete archives (recycling). Media emptied of current archive copies can be replaced with new media and taken to storage, or can be relabeled and reused.

  

Archive Copy Lifecycle - Media Library Concepts

 

SAM software manages the movement of media such as tapes between online mass media libraries and offline/offsite storage facilities.

 

Each tape or magneto-optical disk in a SAM-controlled media library is affixed with a bar-coded label with a unique code called a Volume Serial Name (VSN). The VSN is also written onto the media itself the first time a tape or magneto-optical disk is used by SAM. The VSN on the barcoded label can be read by the library robot and allows the library to identify the tapes or magneto-optical disks it must load into drives. Although the VSN is actually only the number on the label, in practice, users of SAM-FS informally refer to the labeled media as "VSNs."

 

When a removable media library is initialized, it takes an inventory of the media in the library, including the VSNs, the capacity of the media, the current usage of tapes in the library, etc. This inventory is held in a binary file called the “library catalog.” The catalog is fundamental to the functioning of SAM-FS and SAM-QFS, because it contains media library metadata, much as a file system contains file metadata.

 

The library catalog also holds usage information on VSNs and any flags applied to the media by the SAM software. For example, when the recycler runs, it flags media to be recycled “recycle” so that they will not be written during the recycling process. These flags and any others set on VSNs in a library are recorded in the library catalog for that media library. If you want to move a SAM-FS or SAM-QFS file system, the easiest way is to move the catalogs along with the file system on disk and all the media (A library's catalog will eventually be rebuilt if it is lost, so it is not absolutely required to move the library catalogs when you move a file system, but it saves time and shortcuts potential problems.)

 

By default, library catalogs are contained in the directory /var/opt/SUNWsamfs/catalogs, although you can designate a different location in the mcf file (discussed later). Each tape library has its own catalog, and there is also one virtual library called the "historian". The catalogs are in binary and cannot be read directly, but can be viewed with the v option of the samu command, or its command line equivalent, samcmd v (these commands will not work until SAM-FS is completely set up and file systems are initialized). Output (shown below), in order, shows the slot containing the VSN, the time of last use, the number of uses, the percentage of the media used, any flags, the media type (ty) and the VSN. SAM cannot know exactly how hardware compression affects the size of data sent to tape, so the value indicating the percentage use of a tape is an estimate, and these values may exceed 100%.

 

Robot catalog samcmd     4.6.25 16:54:44 Jul 12 2007

samcmd on maryann

 

Robot VSN catalog by slot       : eq 100

slot          access time              count use flags         ty            vsn

 

count 32

0     none                                 20 0%   -il-oCb----- lt  CLN106

1     2006/07/12 16:37             2   3%   -il-o-b-----  lt   000002

2     none                                 0   0%   -il-o-b-----  lt   000001

3     none                                 0   0%   -il-o-b-----  lt   000003

4     2006/07/11 17:02             1   15% -il-o-b-----  lt   000004

 

Archive Copy Lifecycle - Importing and Exporting

 

The process of "exporting" moves the record of a VSN from a media library to the historian, which is the catalog of all exported VSNs. There is only one historian, which contains exported VSN records from all tape libraries attached to the system. The export process removes the VSN’s record from the library catalog, and adds it to the historian. Depending on the library, the export process usually causes the exported tape to be placed in a mail slot for removal by the administrator. When a tape or magneto-optical disk is added or returned to a media library, it must be "imported" before SAM recognizes the archive copies present on the media. Importing removes the VSN from the historian (for previously exported VSNs) and adds it to the appropriate library catalog. In most libraries, it also moves volumes from the mail slot into slots in the library.

 

Example

 

The kind of data storage management provided by Sun StorageTek SAM software might be useful, for example, in a hospital where huge volumes of data are generated and subsequently sit unused for long periods of time. A patient's hospital records might have the following data storage history:

1. A patient comes in for surgery and the patient's file is created by the physician. It is placed on disk for the first time and immediately archived to tape.

2. While the patient is in the hospital, the data in the patient's file is accessed multiple times a day and remains on disk. Each time it changes, it is archived.

3. As the tape library fills, tapes are recycled and relabeled, removing access to obsolete copies of the patient's file. In this setting, obsolete archives are not kept, because in medical practice, a current patient file contains the patient's entire history. Everything that was in the obsolete archives will also therefore be in the current files.

4. A week after the patient is discharged, the patient's file is released from disk.

5. A month after discharge, the patient returns for a follow-up appointment and the patient's file is staged from tape, modified, and archived.

6. When the tape library fills, the tapes containing the last, most current archives of the patient's data are exported, moved to storage and replaced with empty tape.

7. Years later that patient returns to the hospital, and the tape with the patient's file is called up from the storage facility and imported. The patient's file is then staged.

 

In this scenario, SAM manages all movement of data between disk, online tape, and media storage.

 

File Security: SAM-FS/QFS versus Backup Solutions

 

SAM provides file security in a different way from the file security provided by a backup solution.

 

“Backup solution” is a marketing term describing a set of tapes, drives, libraries and software that produces backups, where a backup is a complete copy of an entire file system, made at a specified time to a definable piece of media, or set of pieces of media. SAM should not be considered a "backup solution". It is a hierarchical storage manager and a native backup capability is built into that concept. A backup solution is one way of providing file security and allowing the reconstruction of data on disk. SAM-FS/QFS is another. SAM-FS and SAM-QFS file systems generally provide all the file security needed, and no backup solution is, or usually can be, used with these products.

 

A backup produced by a backup solution is independent of the file system. A file system backed up with a backup solution has no awareness of the existence of the backup, so the backup may be removed to whatever storage is convenient, without the involvement of the file system. SAM-FS/QFS should not be seen as a “backup solution”, because you never get a recognizable backup, as defined above. Instead, the SAM-FS/QFS file system functions in place of a backup solution to provide file security and to allow you to reconstruct data on disk.  The archiving function and the media used for archiving should be viewed as part of a large, complex file system – not as a file system on disk backed up by a backup solution. The SAM-FS/QFS file system is aware of the existence and location of all its archive copies, and they may not be moved from their designated location without the involvement of the file system. You will use SAM-FS/QFS to ensure the safety of your files, just as you would use a backup solution to do so on a UFS file system, but the only aspect of SAM-FS/QFS that resembles a traditional backup is the dump file of metadata, created with samfsdump. If a disk is lost the metadata dump can be used to restore metadata, which is never archived. The metadata can then be used to access data, which is on archive media. If a worksite is lost, offsite storage of the metadata dump and of archive copies allow reconstruction of the SAM-FS/QFS system.  Because you will be using archive copies along with metadata dumps to provide file security, it is essential that these copies be made in a timely manner and that copies are sent to offsite storage.

 

The QFS file system (no SAM) does not include archiving, and can be backed up with any backup solution. When the QFS file system is restored, you must delete the file .inodes (or avoid backing it up in the first place), but otherwise backing up and restoring a QFS file system is like backing up and restoring any other file system.

 

File System Recovery with SAM-FS

 

As part of its role as a hierarchical storage manager, SAM allows for easy recovery of lost files or disks. All files in the SAM-FS or SAM-QFS file systems are normally archived to tape or other media even if they are never released from the disk. In the case of a disk failure, the file system can be rebuilt from these archives and from backups of file system metadata such as inodes and directory structures. When a disk drive fails, the metadata alone can be rapidly returned to the replacement disk, after which desired files can be accessed immediately through staging from media archive. Recovery from disasters such as disk failure is very fast with SAM; much faster than recovery using backup software that returns complete file systems to disk. Using these recovery techniques, archived files can easily be migrated to new storage hardware or to a new host running SAM-FS or SAM-QFS, because the archive copies, which are the portion of the SAM-QFS file system that resides in the media library, are unaffected by the migration.

 

SAM supports up to four archive copies of the current version of a file. These copies can be placed on different tapes or magneto-optical drives, ensuring that copies remain if a tape or removable disk fails. One or more of these current archive copies should also be removed to offsite storage for additional security.

 

Planning for SAM-FS/QFS File Systems: Some admonitions from Sun Support

 

SAM-FS and SAM-QFS file systems work best when they are set up, tested and allowed to run without interference. Frequent changes to configuration files and frequent attempts to tune file systems lead to equally frequent contacts with support personnel.

 

Set up your SAM-FS/QFS file system, test it thoroughly and do not change it thereafter unless there is a problem. Prior to making essential changes, contact Sun support for the best solution to your problem.

 

Properly setting up and tuning a SAM-FS/QFS or standalone QFS file system requires that you understand your hardware and the intended use of your file system. To set up a properly performing QFS or SAM-QFS file system you must know the chunk size and stripe size of your LUNs. You must know the size of the files that will be stored on the file system, and how often they will be accessed after being written. You must know how many files you will eventually have, and how active the file system will be. For acceptable performance, you must have hardware capable of supporting your file system.

 

Typically either SAM-QFS (archiving plus the high performance file system) or QFS (the high performance file system alone) are configured. SAM-FS is not commonly configured. (I have seen it used when customers could not afford the QFS licenses, on workstations where it provides a rapid backup of files for users, or at sites that have been using SAM-FS since before QFS file systems were available.) File systems are most commonly placed on RAID-5 LUNs, though RAID-1 is also used in some situations.

 

The most common sources of difficulty for installations using SAM-QFS or QFS are 1) post-setup changes to the configuration, and 2) inadequate hardware. Be sure that you have adequate numbers of drives and adequate media slots in your library, and take the time to plan and test the correct configuration before the SAM-QFS or QFS system is put into production. Well-designed and administered systems may run for years without problems.  Poorly-designed systems that are changed frequently have weekly difficulties.

 

Master Daemons

 

SAM relies on a hierarchy of daemons that are responsible for carrying out archiving activities, so it is essential to understand the general functions of the master daemons, sam-fsd and sam-archiverd. These daemons are largely responsible for starting and controlling other daemons.

 

The command to start the sam-fsd daemon is added to the /etc/inittab file with the keyword "respawn" the first time that a file system is initialized with the command sammkfs, or the first time that an existing SAM-FS or SAM-QFS file system is mounted, whichever occurs first. At the same time, the daemon is started. Subsequently the init

process starts sam-fsd at boot. If sam-fsd is killed, init restarts it automatically. The sam-fsd daemon is not managed by the SMF (Service Management Facility) in Solaris 10. It is added to /etc/inittab as it is in Solaris 8 and 9.

 

Configuration files for SAM-FS, SAM-QFS, and QFS are all located in the directory /var/opt/SUNWsamfs. They include the mcf file and configuration files for the archiver, releaser, stager, and recycler functions. The archiving configuration file, archiver.cmd, is read by the master archiving daemon sam-archiverd, but changes to any other configuration file must be read by the sam-fsd daemon, which updates other daemons as necessary. This can be done with the command

 

# samd config

 

which forces sam-fsd to reread its configuration files. It simultaneously causes sam-archiverd to reread the configuration file archiver.cmd.

 

The sam-fsd daemon is also responsible for starting the daemons that control hierarchical storage management: the master archiving daemon, sam-archiverd, the releasing daemon, sam-releaserd and the two staging daemons, sam-stagerd and sam-stagealld. Recycling is not performed by a daemon. If sam-archiverd, sam-stagealld or sam-stagerd is killed, sam-fsd restarts it automatically. The sam-releaserd daemon is started only when needed and does not run continuously.

 

The master archiving daemon, sam-archiverd, starts one sam-arfind daemon per file system at file system mount time. These daemons run continuously and are responsible for identifying files to archive. When archive files need to be sent to removable media, sam-archiverd starts one instance of sam-arcopy, which actually performs the write. The sam-archiverd daemon also re-reads the archiver.cmd file, which contains archiving parameters, when the command samd config is run. The sam-archiverd daemon is the only daemon other than sam-fsd to read a configuration file, and archiver.cmd is the only file it reads.

 

The sam-amld daemon is also started by sam-fsd, and it starts the daemons monitoring mass storage devices. These vary depending on the type of hardware, but may include sam-genericd for lower end tape libraries or sam-stkd for StorageTek libraries. If there is a major change to the library configuration, sam-amld must be stopped and restarted:

 

# samd stop

# samd config

# samd start

 

These commands are usually required after SAM is installed and configured to force sam-amld to read configuration parameters, and if SAM-Remote is set up.

 

 

Daemon	Started by:	Starts	Major Tasks
sam-fsd	init	sam-archiverd, sam-releaserd, sam-stagerd, sam-stagealld	starting and configuring storage management daemons
sam-archiverd	sam-fsd	sam-arfind, sam-arcopy	managing archiving, controlling archiver.cmd
sam-arfind	sam-archiverd		identifying files for archiving
sam-arcopy	sam-archiverd		copying files to archive media
sam-releaserd	sam-fsd		releases files
sam-stagerd	sam-fsd		stages individual files
sam-stagealld	sam-fsd		stages groups of files
sam-amld	sam-fsd	various daemons	controls removable storage media daemons

 

 

SAM-FS, SAM-QFS and QFS Requirements

 

Release 4.6 of the SAM-Q software requires Solaris 9 or 10 and various versions of Linux are supported for some configurations as well. All releases of the software run on Sparc systems; Release 4.3 and later will also run on x86 systems. On Solaris 10, SAM-FS/QFS can only be installed in the global zone, does not use the Solaris Management Facility (SMF) and works much the same as it does in Solaris 9. This can cause problems on NFS clients if SAM-FS/QFS file systems are NFS shared because NFS is managed by the SMF. If possible, mounts for SAM-FS and QFS file systems on Solaris 10 should include the option “bg” to prevent issues with the SMF.

 

The Solaris OS requires no special setup prior to installing SAM; the operating system continues to function as it did prior to the installation of SAM-FS, SAM-QFS, or QFS. For SAM-FS, SAM-QFS, and QFS to work correctly, all current Solaris OS patches must be installed.

 

The QFS, SAM-FS, and SAM-QFS software packages can be obtained on a CD-ROM or from the Sun Download Center at http://www.sun.com/download/index.jsp. Click on "Storage Management" and look through the list of products for the SAM and QFS products. SAM-FS/QFS patches may be obtained from sunsolve.sun.com.

 

The disk space used by SAM-FS and QFS file systems is called “disk cache.” Disk cache is disk space reserved specifically file data and metadata. Do not let the term “cache” confuse you. SAM-FS/QFS disk cache is not used for caching in the way that data may be cached in memory or in swap space by other file systems. In SAM-FS/QFS the term “disk cache” refers to online disk space used for the file system.

 

At minimum each SAM-FS file system requires at least one disk device, though any single SAM-FS file system can include up to 252 disk devices. Each SAM-QFS or QFS file system requires at least two disk devices: one for metadata and the other for data, but can also include up to 252. These devices can be in the form of LUNS located either on standalone disk devices or on enclosures of multiple disks. SAM-QFS works well with SAN configurations as well and no special setup is needed for these.  Disk cache can also be in the form of volumes created with VERITAS Volume Manager or with Solaris Volume Manager (Solstice DiskSuite) software. Global raw devices are now supported for SAM-QFS file systems on Sun Cluster. SAM-FS and SAM-QFS require a library of tape drives or magneto-optical drives for archiving. SAM provides drivers for compatible attached libraries.

 

It is a good idea to send at least one of your archive copies to online disks for extra security. As we will see, these online disks do not need to be extremely fast or large or reliable. Customers will commonly use an array they are retiring from data storage to hold online disk archive copies. Increasingly Sun customers perform all local archiving to inexpensive SATA disks, and only archive copies destined for offsite storage are sent to tape.  

 

SAM-FS and SAM-QFS can be deployed with a variety of hardware configurations including disk arrays, enclosed disks, magneto-optical disk libraries, and tape libraries in many combinations. It is rare for a site to use more than one type of library. For simplicity, this document assumes a single disk array and tape library, because tape is, by far, the most popular form of removable media used with SAM-Q. We will assume throughout these documents that the server, disk storage, and tape library have been set up and are operational and that the library is stocked with tapes.

 

Installing the Software

 

The SAM-FS and SAM-QFS software use the Solaris OS pkgadd utility to install software. Prior to installing the software, confirm that the latest Solaris OS patch cluster has been installed on the server. Refer to http://sunsolve.sun.com for the current SAM-FS software patch and the Solaris OS patch cluster.

 

To install the SAM-FS software:

1. Add the software package. In the directory containing the software package type:

# pkgadd -d . SUNWsamfsr SUNWsamfsu

 

The pkgadd utility prompts for confirmation of the various actions necessary to install the packages. Installation must be in the order given, which installs the root directories and then the /usr directories.

 

2. Patch the SAM-FS software, if necessary. In the directory containing the patch type:

# patchadd XXXXXX-XX

Where XXXXXX-XX is the patch name.

 

License keys are not required to run the SAM-FS, SAM-QFS, and QFS software for Release 4.3 or later. Older versions of SAM-FS require license keys, which were placed in the file /etc/opt/SUNWsamfs/LICENSE.<version>, for example, /etc/opt/SUNWsamfs/LICENSE.4.2.

 

If you are configuring archiving, you must update the /kernel/drv/st.conf file with entries for SAM-FS SCSI tape drivers. After the file is updated and the system rebooted, the changes are implemented as part of the kernel.

 

# cp /kernel/drv/st.conf    /kernel/drv/st.conf.orig

# cat  /opt/SUNWsamfs/examples/st.conf_changes >> /kernel/drv/st.conf

 

Finally:

1. Update the PATH variable by adding the following paths to any appropriate initialization files:

/opt/SUNWsamfs/bin

/opt/SUNWsamfs/sbin

 

2. Update the MANPATH variable by adding the path /opt/SUNWsamfs/man.

3. Reboot

# init 6

 

At this point SAM will be installed, but the daemon sam-fsd will not be running. Many commands will not yet work.

 

The file inquiry.conf

 

Production environments use supported hardware, and for such hardware the set-up process above will be all that is required. If you want to configure an unsupported device, such as a DAT tape drive to work with SAM-FS, you will have to add a configuration line in the file /etc/opt/SUNWsamfs/inquiry.conf. The information contained in this line can be found in the device logs, located in /var/opt/SUNWsamfs/devlog, once SAM-FS has been configured, and information on configuring the file can be found in the man page for inquiry.conf.

 

Upgrading SAM-FS and QFS

 

The upgrade process for the SAM-FS and QFS products is straightforward:

 

1.     Idle archiving (if applicable) and wait until all archives have been written to archive media. Check that all archiving is complete with the command showqueue -v.

2.     Perform a complete metadata backup of all file systems.

3.     Perform a complete backup of all configuration files on UFS file systems.

4.     Unmount file systems.

5.     Edit the file /etc/inittab and comment out the line that restarts sam-fsd.

6.     Kill all SAM-FS or QFS daemons.

7.     Remove the old package(s) with the pkgrm command.

8.     Add the new packages with the pkgadd command.

9.     Edit the file /etc/inittab and uncomment the line that restarts sam-fsd if necessary.

10.  Mount file systems.

 

These steps will vary slightly depending on the release you are updating.

 

Configuration files are not overwritten when the package is installed, so should all be in place. The same file systems can probably be used with the new package. Backwards compatibility is only a concern if you want to upgrade from the (pre-Sun Microsystems) SAM-FS 3.5.1 product to SAM-FS 4.3 or later. SAM-FS 4.3, and later will not read the Version 1 superblock used in SAM-FS 3.5.1, and in that case, file systems will have to be remade if you upgrade.

 

Configuring SAM-FS

 

Once SAM-FS/QFS is installed, the SAM-FS/QFS software environment must be configured by setting up a file called the master configuration file (mcf file), and by initializing and mounting file systems. Until that happens most commands will not work and no daemons are running. These tasks are covered in detail in the next paper.

 

File Access with SAM-FS and SAM-QFS

 

The files on the SAM-FS or SAM-QFS file system all appear to be resident on disk. All standard network file protocols such as NFS and applications such as rcp and ftp can be used on files controlled by SAM. User commands such as ls and cp work just as they would on data on a UFS file system.

 

When a released file is accessed from an archive copy by any application, including the archiver, the file will stage to disk unless the “never stage” attribute is set on the file. If the files are staged from tape, the user might experience a somewhat slower response time while files are staged, but otherwise will be unaware that the data is not on disk.

 

If a file has been configured never to stage, its data will be redirected directly into the application from the archive. A file configured to never stage will not be written back to disk unless it is modified. If the file is modified, it will be written to disk even if it has been configured never to stage, and will then be archived again. For example assume a file called “maryann” that has been archived and released and that is configured never to stage.  If a user runs the command:

 

# vi maryann

 

the user will see the file “maryann” displayed on his screen. When he writes the file to disk, the file will be written to disk, its mtime will be updated, and it’s archive copies will get the stale flag. It will subsequently be archived. Unless it has been configured to release automatically when archiving is complete, it will probably not be released. Simply rearchiving a file will not cause it to stage if it has been configured to never stage; it will be rearchived directly from the original archive copy.

 

Whether or not the file is staged, if all archive copies are located on tape, accessing a released file from tape requires use of the tape drives and may therefore be quite slow. File access from an online disk archive is generally much faster than from tape.

 

The behavior of SAM-QFS is somewhat different in the single-writer, multiple reader and in the shared QFS file systems; that behavior is documented in the articles on those file systems. (Thanks to Jonathan Kennedy and Spencer McEwen, Harvard University Library, who worked out these details.)

 

The SAM-FS or SAM-QFS file system itself is maintained by the administrator very much as a UFS file system is maintained. It has a mount point under the root directory (/) and a directory structure, and supports commands such as df. The administrative command du does not work with SAM-FS and is replaced by the command sdu. The command find works on SAM-FS/QFS file systems as it does on UFS file systems, but the command sfind also allows a user to search by SAM-specific attributes such as archive status. See the sfind man page for the very extensive, very useful list of search options. The sfind command is indispensable in writing shell scripts to manage SAM-QFS installations.

 

SAM-Manager

 

The GUI Manager SAM-Manager may be installed on any system in a LAN and will manage all SAM-FS/QFS file systems in the LAN from a single workstation. Depending on the release and build, it may create a default RBAC role called SAMadmin automatically when the start up script is run.

 

You can start using the SAM-manager at the location https://localhost:6789 (don’t forget the “s” in “https”). It will provide a sign-in page to which you should log in as root. Do not disable pop-ups or otherwise configure the browser as that may prevent SAM-Manager from working.