aaron's picture

Disks, RAID, and Xsan Components

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.

brandon's picture

Xsan reviewed at Datamation

With Apple's Xsan Takes a Bite out of Storage Market, noted Mac columnist John C. Welch gives Xsan a fair and modest treatment. In essence, he concludes that Xsan is a good hammer for a midsized nail. On a barely related note, I am truly sick of that cringe-worthy Apple/Bite metaphor in every other Mac news headline I see. Who's with me?

jamesg's picture

Compatibility with IPStor Server

Just to report that we were having very odd problems trying to use Xsan 1.0.1 with our FalcolnSTOR IPStor Server storage managers.

We've been using version "v4.00 (build 883)" (fully patched) to manage the volumes from our mainly DotHill disk arrays for the best part of two years now, and they've worked correctly with Solaris 8 and 9 (using Veritas Volume Manager and Sun's DiskSuite; with ufs and vxfs), RedHat Linux 7.3 and 9 (using direct mounting of the LUN, and with LVM; with ext3 and xfs), Novell Netware 6.5, Windows 2000 Server, SGI Irix 6.5.19 (with xfs).

We could even import volumes from the IPStor managers to OS X Server 10.3.9, formatting them HFS+ and mounting through the Finder. But Xsan 1.0 and 1.0.1 refused to acknowledge that there were any LUNs available for it to use.

After chasing red herrings with CLI forced labelling of disks, I discovered the disk reject logs, and saw that the problem appeared to be that Xsan thought that the virtualised volumes had a disk geometry of zero bytes per sector. Bear in mind that these volumes were working happily on all of the other OSs listed above.

This is just to report that, following a major upgrade of the IPStor Server software to v4.50 (build 948), Xsan 1.0.1 is now happily seeing and using the virtualised volumes, and using the correct bps of 512.

This was clearly an issue with the IPStor Server software, but it's of note that it only affected Xsan out of all the volume management/file system/operating system combinations we had used before.

xadrdm's picture

Recommendations on optimizing performance

I have 2 x 2.5TB XRaids. What seems to be the recommended configuration for performance?

1) 2 drives striped Raid 1 for MDJ, The remaining 5 disks striped as Raid 5 in a storage pool with like LUN's from the other drive banks? (Basically 4 LUN's each with 5 disks @ Raid 5 - with proper affinities applied)

or

2) 2 drives striped Raid 1 for MDJ. The remaining 5 disks unused. Then take 3 Lun's each with 7 disks @ Raid 5)

I realize in solution 1 that 4 controllers will "theoretically" get better throughput, but I've also heard that sharing a controller with the MDJ Storage Pool can impact performance.

And finally, both of the above configurations assume there will be extra drives left over to put into different storage pools. Is there a utility available that will let me determine the performance of a storage pool (or the directory within the XSan Volume)? It seems that most Speed test only work on the entire volume.

Thanks for your help.

joannou's picture

Xsanity Defrag 1.0.1 Released

[img]http://www.xsanity.com/images/XsanityDefrag.png/img

[url=http://www.xsanity.com/easyfile/file.php?download=20050428164955642]Down... Xsanity Defrag 1.0.1/url

Xsanity Defrag 1.0.1 has been updated for Xsan 1.0.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.

Open files or files that have been modified in the past 10 seconds are not defragmented. If a file is modified while defragmentation is in progress, defragmentation will stop and the file will be skipped.

Xsanity Defrag will run only as superuser. It is recommended that Xsan volumes to be defragmented be unmounted on all client computers before defragmentation.

THE SOFTWARE IS PROVIDED "AS IS" AND WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES AND/OR CONDITIONS OF MERCHANTABILITY, OR OF FITNESS FOR A PARTICULAR PURPOSE.

joannou's picture

Xsanity Defrag 1.0.1 Released

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

Xsanity Defrag 1.0.1 has been updated for Xsan 1.0.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!

aaron's picture

Data, Metadata, and Fragmentation

Question: I have a simple Xsan: two-seats, one Xserve RAID, one storage pool. After copying a whole bunch of tiny files, via the Finder, to the SAN, any write creates a file with at least 30 extents, sometimes as much as 500 on a single file. I tried defragmenting the whole volume, deleting the directories that had the zillion little files, I even upgraded the clients to OS 10.3.9/Xsan 1.0.1. The large-extent render files are not playing back unless I defrag them. My questions are: Are 30-500 extents for single files (100-500MB render files for example) normal? Do you know of anything to cure this poor file system?

Answer: We need to understand several behaviors of Xsan:

  • Metadata is stored in blocks contiguous with data
  • Metadata is written to disk after every new file created
  • Metadata is easy to fragment, and difficult (impossible?) to defragment
  • New files use the first available free space on a storage pool

Read more for more info.

aaron's picture

Best way to update to 1.0.1?

So, what's the best way to update to 1.0.1 without taking everyone offline?

ron's picture

Xsan 1.0.1 Released

Apple has announced the general availability of the Xsan 1.0.1 update. The 1.0.1 Update delivers overall improved reliability for Xsan and requires the use of Mac OS X or Mac OS X Server version 10.3.9. It includes improvements for:

  • using the mv command to move files from Xsan (ACFS) to Mac OS Extended (HFS+) volumes
  • saving files over 4GB via SMB/CIFS to an Xsan volume hosted on Mac OS X Server
  • greater server stability when resharing Xsan volumes via NFS
  • eliminating spontaneous metadata controller failovers that can result in slow file performance

To download this Update, please visit the website: http://www.apple.com/support/downloads/xsanupdate101.html.

For detailed information on this Update, please visit this website: http://www.info.apple.com/kbnum/n301211.

aaron's picture

Tied to Xsan version 1.0

Even through we're just running Apple's command for defragmentation, we thought there may still be problems with untested versions. So Xsanity Defrag checks your version of Xsan when it launches. If it isn't Xsan 1.0, it won't launch.

When Apple releases a new version of Xsan, we'll quickly test and update Xsanity Defrag to match.

Pages

Subscribe to Xsanity RSS