It occurred to me that I’ve been talking about Xsan for awhile but I didn’t start with the key element of what makes an Xsan an Xsan. It’s metadata. Metadata is typically the extended attributes of a file (eg – with iTunes it is the artist, keywords, how much you like or dislike the song, etc). With Xsan metadata is information about where all of your files are stored, or if they’re broken into many parts (and most are) then it’s the information needed to find those parts across the various LUNs, Storage Pools, Blocks and Stripes that they sit on and how to then put those parts back together. This is done using what amounts to a catalog of iNode information and where each of those iNodes points. The metadata for a given file system is actually stored on a (preferably dedicated) LUN and does not reside on a metadata controller. Metadata controllers interpret the metadata and therefore allow hosts to mount a volume and access data within the volume without latency to try and figure out where everything is.
A typical Metadata LUN will be a mirror. The reason for this is that mirrors rebuild quickly. Space is typically not a concern as 1GB is good for about a million files in most cases.