Monday Mar 17, 2008

SAM-QFS Code Open Sourced

We are please to announce that we have open sourced the SAM-QFS code! This major contribution to the OpenSolaris community is available on We are very excited to take this big step in creating an open source community around SAM-QFS and continuing to grow Open Solaris as a premier storage OS.

So, I'd like to explain where we are today and where we are going relative to posting the source. Getting all of the Sun SAM-QFS IP posted for Community viewing and download was priority number one. This announcement is about that first milestone. We are looking forward to connecting with developers, early adopters, and users through our open source effort. Eventually we plan to externalize the source via Mercurial to facilitate community code contributions.

What we are delivering is our current development source. Our goal is to have the community be part of the development process, so we are intentionally posting our development work instead of released software, such as the SAM-QFS 4.6 code. By delivering development source, the community can influence and contribute to development of future releases, and it allows early adopters to quickly get access to the latest features. This change should benefit not only the future SAM-QFS releases and therefore customers. In addition, it will benefit those that would like to adopt or experiment with Solaris as a storage platform.

This initial post is a gzipp'd tarball of our latest development build. Some third party components were removed for legal reasons. Therefore, this first posting won't build unless the missing third party components are added back or coded around. This is a temporary solution until we either get legal permission to post the third party source or recode those sections so that they can be built with or without the third party components.

We look forward to feedback about what we have posted and what you as the SAM-QFS community would like to see in future source code uploads. To that end, we have two discussion lists for communication.

1) SAM-QFS-DISCUSS - The discussion list for general topics or issues

2) SAM-QFS-DEV - The development alias for specific questions about source, source contributions, or code reviews

Again, please join us at the OpenSolaris SAM-QFS project page ( We look forward to your comments and involvement.

'til next time, Ted

Thursday Mar 06, 2008

Development update: Archiver

We are actively working on the archiver to improve SAM scalability and performance. One area we are focusing on is reducing the scanning and therefore metadata footprint of the archiver. Currently, the noscan method of the archiver gathers inode (file) events to determine whether and when an inode needs to be archived. After receiving the event, the archiver schedules a scan of the associated directory. The list of directories to be scanned become the archiver's worklist. We are working to improve archiver performance by changing the sam-arfind daemon's worklist from a list of directories requiring scanning (in order to find files requiring examination), to the actual list of file inodes requiring examination.

Keeping the actual list of inodes should significantly reduce the frequency scans done by the archiver. In general, most inode events would require examination within minutes or hours. However, for those longer time frame examinations, only those files that need to be examined within a "rolling window" of time are kept in the worklist. The duration of the "rolling window" is specified by the 'background_interval' in the archiver.cmd file. The default might be 24 hours. Files that require examination after this time will be found during the next background scan. The time of day for the background scan is specified by the 'background_time' in the archiver.cmd file. The default might be (midnight). The intent of these tunables is to allow the administrator to schedule the background scans at a frequency and time that minimizes archiver scan impact to production.

'til next time, Ted

Wednesday Mar 05, 2008

New 4.5 and 4.6 patches released

The 4.6-04 patch and the 4.5-06 patch are now available for download. In addition to the usual bug fixes, we added quite a bit of new support in the 4.6-04 patch.

Newly Qualified with SAM-QFS 4.6-04

1) The Sun StorageTek 5800 System Version 1.1 is supported with SAM-QFS.

2) The HP LTO4 tape drive is now qualified with SAM.

3) ACSLS 7.2 is now qualified with SAM-QFS.

4) The Sony Super AIT2 tape drive is now qualified with SAM-QFS.

5) The HP SL48 library is now qualified with SAM-QFS

6) The Sun VTL and the following drives are now qualified with SAM-QFS: HP LTO3 IBM LTO3 STK 9940C STK 9840B STK T10K

7) Intel EM64T 64 bit architecture servers are supported with SAM-QFS, including SAM and Shared QFS MDS on Solaris 10 and Shared QFS clients on Solaris 10, Red Hat 4, and SLES 10 OSs.

Here is the link to the wiki:


    'til next time, Ted

  • Friday Jan 25, 2008

    Development update: Journaling

    We are forging ahead with development of the next SAM-QFS release. Although, I cannot make any promises about features (This is software development after all), I wanted to provide a peek at some of our feature development. I'll try to provide these updates on a regular basis. I hope you find these useful.


    One of the features we are working on is journaling. Some of the benefits of jounaling to QFS are reduced need for samfsck and increased metadata performance. While QFS has a consistency model that generally does not require an fsck, except to reclaim lost space and clean up orphan inodes, journaling will reduce the need for this type of clean up after a panic. The bigger benefit to QFS is the increase in metadata performance. Journaling can reduce the frequency of disk accesses required for metadata-intensive applications. This boosts the performance of QFS. In some preliminary tests, we have already seen a significant increase in performance on Shared QFS clients with journaling enabled on the metadata server. I'll try to report some real numbers as development progresses.

    'til next time, Ted

    Wednesday Dec 12, 2007

    New SAM-QFS patch released for download

    We recently released the third 4.6 patch (4.6-03). A few items that I think are exciting support additions in this patch, on top of the usual bug fixes.

    1) 256 node support for Fibre Channel.

    \* This is part of our continuing effort to increase the scalability of Shared QFS. This should be welcome news for those customers already running 128 nodes and looking to increase node count. It also enhances Sun's HPC file system offering for small to mid size customers.

    2) New tape drive and library qualifications.

    \* The Sony CSM-20S library has been qualified for use with Sun StorageTek SAM-QFS 4.6 Patch 03. The device type is 'cs'. The import command in SAM for CSM-20S library imports one tape at a time.

    \* The IBM LTO4 tape drive has been qualified for use with Sun StorageTek SAM-QFS 4.6 Patch 03. The device type is 'li'. Although no changes are required in /kernel/drv/st.conf for SAM support of the IBM LTO4 drive, the latest st patch is required.

    \* The Quantum DLT-S4 tape drive has been qualified for use with Sun StorageTek SAM 4.6 Patch 03. The device type is 'lt'. Although no changes are required in /kernel/drv/st.conf for SAM support of the DLT-S4 drive, the latest st patch is required.

    3) New server architecture support \* Intel EM64T 64 bit architecture servers are supported with Shared QFS

    Also, take a look at our new Wiki for more information on 4.6. It provides a growing wealth of technical information on SAM-QFS releases, including a patch download link, documentation, a growing faq, and more. Here is the link to the wiki:


    Lastly, we are still forging ahead with our open source plan. We've started a discussion alias "" and added the source for sdu, sls, sfind, and star to the existing Libsam code. Expect more code in the coming months. I also encourage you to join the discussion alias and become part of the community. Here is the link to the open source page


    'til next time, Ted

  • Wednesday Apr 25, 2007

    SAM/QFS Directory Performance

    With the release of the 4.6 version of SAM and QFS on April 3rd, I thought it would be appropriate to start discussing some of the improvements included in this update. Specifically, SAM/QFS added improvements to directory lookup performance. This is part of our effort to continue scaling SAM/QFS. I thought I'd address the directory lookup improvements in this article

    This phase of the directory lookup performance improvements is primarily targeted at lookups for names that do not exist. The system calls that receive the greatest benefit are create(), link(), and rename(). System calls other than these three will not benefit greatly from the 4.6 changes. We would like to further expand the system calls that benefit in the future.

    The SAM/QFS performance group ran a comparison test for these system calls on small (2 CPUs), medium (4 CPUs), and large (20 CPUs) configurations comparing 4.5 to 4.6. The tests were run using a C program on a QFS 'ma' file system with 'mm' and 'mr' devices. They reported a 66 times improvement for the case with 128K zero length files in a directory on the large configuration. On the small configuration, a 26 times improvement was realized for creation of 100K files in a single directory. Additionally, on the medium configuration, rename, symlink, and mkdir performance comparisons showed 970, 169, and 4 fold increases respectively. In general, the larger the directory, the greater the gain expected with 4.6 over 4.5.

    It is important to realize that the performance of the application in using these system calls must be sufficient to benefit. For example, when the create logic was moved from a C program to a shell script on the small configuration, the performance improvement was only 2.4 times compared to the 26 times with the C program. Clearly, the shell script could not create files quickly enough to see the same benefit as the C program. This needs to be kept in mind when developing performance tests or understanding performance results.

    We also took a look at some of the SAM commands that are run on QFS. The command that received the greatest performance gain in 4.6 was the samfsrestore command because it primarily does lookups of directory entries that do not exist. We observed a 2 times performance increase for a samfsdump file containing a few million files. You can't expect hundreds of times of improvement at this level because the directory lookups are only a subset of the operations performed by samfsrestore.

    The really nice point for existing SAM/QFS users is that, other than a 4.6 upgrade, you do not need to do anything to obtain the improvements. The directory lookup performance improvements are compatible with all 4.x QFS file systems. All directories greater than 4K in size will automatically use the new directory caching lookup scheme.

    All in all, I think this a big benefit to SAM/QFS users and shows the commitment to continue scaling SAM/QFS.

    'til next time Ted

    Wednesday Feb 21, 2007

    Welcome to SAM-QFS Weblog

    Welcome to the Sun SAM and QFS Blog! SAM is storage archive manager which manages data (both on disk and tape) with amazing ease and transparency to the user. QFS is a shared file system which scales from 1 to 128 nodes and virtually has no limit to the amount of information managed. I know there is a community of people out there that are already familiar with this software, but I'd like a brief introduction of SAM and QFS for those that are not.

    So, what is SAM and QFS? In a nutshell, it provides a complete data management system but consists of two integrated software products SAM (Storage Archive Manager) and QFS (High Performance Shared SAN file system).

    The Shared QFS file system is a high-performance, 64-bit Solaris SAN based file system. This file system ensures that data is available at device-rated speeds when requested by one or more users. The Shared QFS file system's inherent scalability allows an organization's storage requirements to grow over time from Terrabytes to Petabytes with virtually no limit to the amount of information that can be managed. In addition, the Shared QFS file system allows you to scale from 1 to 128 compute nodes to let you scale your data sharing with your computational needs. QFS also let's you tune your I/O access to your specific data profile to maximize your read and write performance to disk. Shared QFS is also part of Sun's heterogeneous SAN story and supports linux client nodes in addition to the native Solaris clients. We also support IBM Sanergy clients in a QFS shared configuration.

    As I said, SAM is tightly integrated with QFS. The SAM adds the features of a storage archive manager to QFS. A SAM-QFS file system configuration allows data to be archived to and retrieved from local or remote automated tape libraries or disk at device-rated speeds. SAM manages QFS data online, nearline, and offline automatically and in a manner that is transparent to the user or application. Users read and write files to a SAM-QFS file system as though all files were on primary storage. In addition, SAM protects QFS file system data continually, automatically, and unobtrusively. Multiple file copies can be made to many media types and storage tiers in a standard format. This minimizes the requirement for traditional back-up only and provides fast disaster recovery in an effective long-term data storage solution. A SAM-QFS file system configuration is especially suited to data-intensive applications that require a scalable and flexible storage solution, superior data protection, and fast disaster recovery. This solution also includes an integrated volume manager, automated and flexible policy management, GUI-based management tools.

    On the whole SAM-QFS solution solves data management needs with ease and reliability and we're just getting better and bigger. Look here for technical discussion around SAM-QFS and it's future development.



    Ted Pogue


    « July 2016