Take Off That Umask So We Can See You

Background

When a user creates a file in OS X, that file receives an initial set of permissions determined by the system's umask, or user file mode creation mask. The default umask in OS X dictates that the creator of a file has full read and write access, while everyone else has read-only access. This pesky default umask has bothered OS X users for quite some time. Users create files and drag them to server volumes shared by groups, only to realize that other group members can read the files, but not modify them. Collaboration is effectively broken, but not beyond repair ...

We're happy to announce an update to our home-grown Xsan defragmentation app, Xsanity Defrag.

Xsanity Defrag 1.1 has been updated for Xsan 1.1. The app is a GUI wrapped around the snfsdefrag command-line utility that ships with Xsan, allowing you to defragment files on Xsan volumes or storage pools with ease. It indicates the level of fragmentation on your Xsan volumes or storage pools, and allows you to monitor the progress of the defragmentation process.

We'll be providing support for the app in a dedicated forum on this site. All feedback is welcomed!

Xsan 1.1 Update for 10.4

Xsan 1.1 Update for 10.3.9

Xsan Admin 1.1 Update (10.3.9 or 10.4.1)

The much-anticipated Xsan 1.1 updates are finally available for download. While each of the three above are obtainable via Software Update, you might prefer to check out these standalone installers. The release brings Tiger compatibility, new documentations, and a number of performance improvements, but no few new features. The updates are free, and your existing Xsan serial numbers will of course continue to work. Don't forget to return to our forums to discuss your update experiences.

From the release notes:

Important Notes: If any system in your SAN is running Xsan 1.1 on Mac OS X v10.4, then your metadata controllers must also run the same. You can't use a metadata controller running on Mac OS X v10.3 if any client is running Xsan 1.1 on Mac OS X v10.4.

We read this to mean the following: If all your systems are running OS 10.3, a mix of Xsan 1.0.1 and 1.1 is O.K. But if any client has OS 10.4 and Xsan 1.1, then you must upgrade your metadata controllers to OS 10.4 and Xsan 1.1.

The private Ethernet network for metadata is one of the more obscure parts of an Xsan. The goal is to create a very low-latency communications channel for SAN metadata. In other words, when a client clicks "Capture Now," it needs to ask the metadata controller for the location of free space on the SAN. You want the metadata controller to return its response with no delay.

See below for some tips about this network.

Courtesy of Tekserve, here are two charts to illustrate how disks, RAIDs, and SANs are built up. Update 9 June 05: whack found a few errors in the original posted diagram. We've revised based on those comments. This is now the updated diagram.

Disks & RAID covers physical disks, arrays, partitions, slices, RAID sets, and volumes.

Xsan covers disks, LUNs, storage pools, affiinities, and volumes.