Long ago, I did an article on disabling those pesky files that show up for Windows computers but not Macs on network volumes when you browse folders. These are metadata files and have a number of uses. But if you have a lot of files in a folder on a USB drive or if you move the USB drive to a Windows computer, you might not want .dsstore or metadata files on USB drives either. To disable, use the following command, which writes a DSDontWriteUSBStores boolean key into com.apple.desktopservices: defaults write com.apple.desktopservices DSDontWriteUSBStores -bool true
-
-
Xsan Command Line Options In Mavericks Server
Before I get started, I just want to point out that the old commands all still work. There are some newer things, but nothing earth shattering. Let’s start out with what’s actually available in the Server Admin CLI: serveradmin. The serveradmin command, followed by settings, followed by san shows a few pieces of information: bash-3.2# serveradmin settings san san:computers = _empty_array san:primaryController = "95C99FB1-80F2-5016-B9C3-BE3916E6E5DC" san:ownerEmail = "krypted@me.com" san:sanName = "krypted" san:desiredSearchPolicy:_array_index:0 = "" san:serialNumbers = _empty_array san:dsType = 0 san:ownerName = "Charles Edge" san:managePrivateNetwork = yes san:metadataNetwork = "10.0.0.0/24" san:numberOfFibreChannelPorts = 2 san:role = "CONTROLLER" Here, we see the metadata network, the GUID of the primary (active) MDC, the name…
-
Changing Metadata Networks From The Command Line In Xsan
Awhile back Apple published an article on switching the network interface used in Xsan for Metadata networks. The article provides the following steps: Use Xsan Admin to stop the volumes (see below). In Xsan Admin select Overview. In the lower right corner, click the gear icon and choose “Edit SAN properties”. Select the Metadata Network that you want to use. Click Save. Restart the volumes. Note: If all controllers and clients are not on the same subnet on each network, the Save button will be dimmed. Adjust the clients and controllers so they are on the same subnets. This typically works great; except the fact that the article has been…
-
Integrating Final Cut Server with MediaBeacon
-
Defining MultiSAN
In Xsan 2, MultiSAN was introduced. MultiSAN allows you to assign different sets of primary, secondary and tertiary metadata controllers to volumes. This provides a performance benefit for some environments that have saturated resources on a given metadata controller. However, MultiSAN does not allow you to build separate SANs. All of the volumes are still members of that single “Xsan”, meaning that volumes can be mounted and/or controlled for any of the clients. You can have 2 volumes, each with a dedicated metadata controller, but both sharing a single backup metadata controller. You can also have 2 volumes, each with a dedicated metadata controller that fails over to the other…
-
Podcast Producer Command Line
At the end of the day, Podcast Producer is a fairly straight forward solution. You have a nice little GUI application that users can use to publish Audio, Video, Screencasts or files to an rss feed. Using that rss feed you can then integrate that data with a number of other solutions, including those I’ve discussed over the last few days. You can also use Podcast Producer to remotely fire up bound cameras and begin Podcast Producer workflows, which means you don’t even need to be at a conference, in a shareholders meeting or in a classroom to capture video from cameras. But the real power and flexibility to Podcast…
-
Stripe Breadths on Metadata LUNs
The default stripe breadth on a metadata storage pool is 256 blocks. However, this is way, way too high. Quantum recommends using a 16 or 64 block stripe breadth for metadata storage pools. If you have a relatively small volume with a small number of files then use 16 and if you have a larger environment with big files use 64. As with many things re: Xsan the tuning per environment is where you will get the biggest bang for your buck, but it is worth noting that no matter which way you go, this is a setting that should be changed on each deployment in order to keep with…
-
Xsan: Metadata
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…
-
Xsan: Zoning and Metadata
Only the MDCs are required to see the Metadata LUN. The rest of the clients receive the extents from the MDCs to write to the “data” LUNs. Yes the clients need to see the Data LUNs, but clients do not need to see Metadata LUNs. Before you can upgrade a client to an MDC though, verify that you can see the Metadata LUNs if you are zoning this way. It’s the most secure way but requires a little extra zoning.
-
Xsan: Multiple Volumes
In Xsan 1.x you can have multiple volumes. Each will consist of a given number of Storage Groups that in turn consist of a given number of LUNs, as we’ve described in the past. If you have multiple volumes then they will all use the same Metadata Controllers. Each additional volume will also need its own dedicated Metadata LUN. Therefore, if you have 4 volumes, with 4 LUNs of data storage in each volume then you will have a total of 16 LUNs for data and another 4 for metadata to total out 20 LUNs. Essentially by splitting it up this way you are loosing 4 LUNs (up to 20TB…