Good morning. So I'm standing between you and lunch, I believe, so we'll try and make this either an opportunity for you to get those juices going to look forward to lunch or certainly try and make this an interesting session for you. As mentioned, I'm the Director of Engineering for Pro Video Applications that includes Final Cut, Final Cut Express, Final Cut Pro, Pro Video Codex, and some other projects within our Pro Applications division. I'm going to be talking today about the Xsan product and how it fits into the video workflow. And although I will be talking from the perspective of Final Cut Pro, it actually is very applicable.

It's applicable to anyone in the applications domain who's dealing with media in an Xsan environment. It's also, I think, you'll find it appropriate for anyone who's dealing with the creative professional marketplace in general. There's a number of different tools that fall into this category, and Xsan is an excellent tool in this space. But it provides some interesting challenges as you're dealing with media, and we'll talk a lot about that today. Certainly, folks who are interested in Xsan, I think, are going to be talking about the Xsan product.

And folks who are dealing with site administration, I think, will find this interesting as well, because setting up this environment is actually the biggest challenge that we'll be talking about. So as we get into the talk, first I want to talk a little bit about, kind of set the context around how video editing, you know, kind of the view of video editing from the editor's view, from the kind of creative professional's view, and what their expectations are.

And then we're going to get into how this applies to Xsan environment. And how shared storage and work group computing kind of changes that model and impacts that model in a pretty significant way. And then we'll finish up with a little bit of thinking about where we go from there.

So first to get into video editing today, I think one thing to understand in the marketplace right now is that the focus is around as much performance and real-time capability as you can possibly get out of the hardware. That's certainly what drives the market in a big way. They're looking for the fastest hardware they can get, the fastest storage they can get. They're looking for as many streams of video, as many effects, as much real-time capability as they can possibly get out of the system.

And that's driven around a number of different kind of workflows, both from the kind of media that people are dealing with and the kind of people that are working with the media. So that's everything from the individual independent production house, people who are event videographers who are producing corporate videos, to the independent filmmakers, to small work groups of people who may be working on short-form commercials or movie trailers. trailers or doing music videos, all the way up to broadcast television, how-to shows on HDTV and movies that you go to see at your local movie theater. All of that is expected out of today's existing tools and hardware.

It's a huge range of expectations, and it drives a large number of different kinds of media that people have to work from. If you're dealing with film, you're obviously not working with film directly in the computer, but taking it into some type of offline format. But many of, for news gathering and for other things, they're dealing with DV25, your standard camcorders, if you will, all the way up to your news production, high definition, uncompressed standard definition for TV, uncompressed high definition, as well as other types of media like audio and stills. One thing that's really interesting to consider as you're looking at the performance issues around dealing with this media is the kind of data rates that you're dealing with for this kind of stuff.

For your conventional DV25 or your standard mini DV camcorders, it's in the range of 2.8 to 3.6 megabits per second of information. And as you go up through the different types of media from DVC Pro 50 and DVC Pro HD, the data rates, of course, go up appreciably. When you get to uncompressed, things get really complicated because you're dealing with just monstrous amounts of information.

The good news as compared to things like the various DV formats is these are uncompressed. So the tradeoff there is computational complexity, if you will, having to decompress and recompress that information as you're dealing with it, as opposed to moving just large quantities of bits. For all this data, I want to remind you again that people today are looking to get as many streams of video and effects as they possibly can through the pipeline.

And today, with Final Cut Pro, for example, we deal with a number of streams of video of various types at a real-time level without any additional hardware on a dual processor G5. So people expect that if they're going through the creative process that they're going to be dealing with lots of streams of video and they're going to be doing lots of things and expect real-time behavior.

All of the video, of course, I think it's worth mentioning, kind of in contrast, that there's also a lot of streams of audio to be dealt with. But it's really interesting as you look at the upwards of 100 megabytes per second for uncompressed HD, you're only talking 192 kilobytes per second for audio. But usually people are dealing with many, many streams of audio at a time. But there's a very large range of expected data rates for the kind of media that you're dealing with.

In a typical project, and this is a project in Final Cut, that I think it again is worth noting that typically there's a number of streams of video that people are dealing with. If you look at something like a commercial today, a commercial actually has lots of streams of video going on at once. There's usually various motion graphics pieces.

There's multiple camera attacks that are coming in and they're cross fading or moving across the screen. There's a lot of stuff people are doing. And you may not typically think of, in the normal process, how many streams of media that people are dealing with, but it's quite a lot.

One thing that's very, very common in the case of audio is that people are dealing with usually upwards of 24 tracks of audio. Certainly when it all gets done, it all comes down to one stream of video and maybe a stereo pair of sound. But when they're going through the creative process, there's usually lots of different layers of the stuff that is getting composited together at various levels. And as they're working with it, they expect to see it, listen to it in real time.

So it all comes down to really the way today's model of creating video is it's very much a single system workflow that people have really optimized their process around very high performance single system solutions. Brett Halle And while they may be in an environment with many different machines, you know, today most of the media tends to be moved around, you know, via the network or, you know, by taking that little firewire drive and going from one system and doing the sneaker net thing.

Brett Halle And the downside to that model is that you end up getting a huge amount of media that's duplicated all around the enterprise. It's not very efficiently used and it's not very effectively used. Brett Halle The upside is you've got a huge amount of power that you get out of it. Brett Halle And you can't have that single system because you can make a lot of assumptions about being able to use every bit of that bandwidth.

Brett Halle The other downside to having all that media duplicated around the environment is that you, you know, dealing with backups because it's all distributed around your enterprise or infrastructure and dealing with media security, which tends to be a really big issue is, you know, for example, in for the folks who are doing maybe trailers or, you know, trying to do, you know, unreleased movies.

Brett Halle They're trying to keep. Brett Halle You know, pretty tight control over that media before it gets out, you know, gets leaked out and put on the on the Internet. Brett Halle So doing that when all that media is being sneaker netted around anyway in a firewire drives makes it even easier to have that sneaker netted right outside the front door.

Brett Halle And there's certainly a number of other challenges that a single system workflow, you know, has. Brett Halle It just really makes the processes you're working as a group very, very difficult. Brett Halle And that's where XAN comes in. Brett Halle XAN really provides an opportunity for you to be able to do a lot of things. Brett Halle XAN really provides an opportunity for multiple clients to work together to share data over what's the really most important part of this thing is a very high speed interconnect.

The difference today when you're dealing with a network file system solution in video is it just isn't workable. We talked about the number of streams of video that people expect to work with. Over a network infrastructure, typically you just can't get that type of flow. The Xsan environment really provides an architecture and a design that makes it possible for media-rich environments to be able to share information because you get pretty much the benefit of local speed interconnect because of the fiber and the way that the file system in Xsan is designed relative to how something like a network file system is designed.

Certainly, as we talked about the negatives, there's a lot of single system environment. As we move to shared storage, there's a lot of benefit here. Being able to get to the point where you can actually share media assets within an organization is a big deal. If you're dealing in broadcast, for example, you may have a lot of stock material that you deal with that gets brought in that you really want to be able to use over and over again. If you have to copy literally terabytes of data around to each one of your workstations in order to be able to make that stuff useful, it makes it very ineffective and a horrid use of your storage.

The other advantage of Xsan's shared storage environment is the ability to consolidate that storage. Typically, it's a very good idea to have a shared storage environment. You have a lot of material that you're sharing amongst groups of people, not just what you're working on right now, but a large amount of stock material or material that's potentially coming in from various sources. Again, avoiding having to have the large capacity storage on each of those workstations is a really big plus. It saves a considerable amount of money.

The other big benefit is as you look at the economics of video environment that one of the biggest and most expensive pieces these days is getting to be the acquisition devices themselves, the decks. Particularly as you start talking about high definition or film. Those pieces of equipment are somewhere on the order of 50 to 100,000 to potentially up to a million dollars in order to be able to acquire that media into digital form.

It's not the kind of thing you're going to stick on every one of the workstations within your environment. So being able to get to the point where you get shared storage, you get also the benefit of being able to reduce the number of equipment costs that you have for acquisition. Because you can centralize that. Get the materials. Reel into a place where people can share it.

And avoid having to have lots of redundancy as far as that kind of equipment is concerned. Obviously the benefits of being able to now have that information there means that you can actually start putting together workflows within the workgroup. It means you can get material that can go from editor to editor or to creative professional for the different parts of the creative process. Because they have the ability now to be able to all get to the same media. And then the other big benefit is that you can get the same information from the same media. And that's the benefit of having the same information.

As I talked about a little bit earlier, the issues of single system workflows is that the security is a real challenge. That sneaker net approach of moving media around is a big problem in areas that are dealing with potentially unreleased material movies or other things. And being able to get to the point where because you now have central control of your media and being able to start applying the kinds of permission capabilities that a Unix system and a shared system can have. storage system enable means that you also can start to control the security of your information.

Being able to make sure that you can say who it is that can actually see the material, who is it that's allowed to change it, and basically get to the point where you have a lot more manageability of your assets. And of course, probably the most important part of this whole thing is finally being able to get to the point where, because all your materials together, that it becomes actually feasible to back it all up.

However, with all those good things, there's a number of things to consider when you're dealing with putting together a Xsan environment. One is performance. Remember, we talked about single system performance or what people expect today in the creative process. They're getting every single ounce of power that they possibly can get out of that. As soon as you try and distribute that now, one of the challenges is trying to rein in and control the ability to continue to get that kind of performance.

The other issue is dealing with redundancy. Shared storage is great because you can all share it, but you now have the opportunity for single point of failure. In that situation, you need to be thinking about what do you do to make sure that you don't put your enterprise at risk because you now have a single point of failure. Those individual workstations are great.

If one went down, you still have the other five of them that you had up and running. But again, this is one of these, how do you manage the tradeoffs of being able to get the shared storage? Being able to get that sharing and make sure that you don't put yourself, enterprise at risk in the process.

Security, while it's a really important thing to get in there, it's a really hard problem to solve. And we're going to talk a little bit about what some of the issues are there. But I want to prepare you that getting and putting together the security infrastructure that you need in terms of managing multiple users is very difficult. There are a lot of challenges today in terms of dealing with collaboration. It's a real plus, but you've got to think it through ahead of time to understand what it is you want to try and accomplish here. Let's start with performance first.

The goal in a Xsan environment really is to get back, trying to make sure that you can get to that single system performance. That's what your editors are going to expect, that's what your creative professionals and your enterprise is going to expect because you want to be able to take advantage of the creativity that being able to do all these things in real time enable.

The challenge is you've got to be thinking about now that you are spreading potentially the performance load or the expectations with a large number of clients within your environment. Let's say you're putting together a five system Xsan and you're all going to some set of central storage. You map that against five individual systems that had their own local storage.

Remember, there's one common element in that, which is the storage, which is now getting hit by five times as many. People as it would be if you had them all completely isolated. And so you need to make sure you understand what each of the clients within that environment are actually doing.

What kind of media are they actually working with? And how many streams of video or media are they typically dealing with in the projects that they're doing? Like I said, if you're talking about something like commercials, commercials tend to be a good example where lots of streams of video. As you see these things on TV, it's all about transitioning between lots of different shots.

There's a lot of motion going, a lot of activity. If you look at something like more of a conventional film, you tend not to get quite the large number of streams that you deal with because you're dealing with a lot more long form material. But you have to look at the kinds of things that you're doing and factor that into the process. You need to kind of go back to that graph that I showed earlier in the slides and map the kinds of things that you're doing against the size of the streams and the number of streams to understand, what exactly you're doing in terms of the data flow.

One of the things that you should also consider as you're dealing with single, trying to get to single system performance is that in your fiber infrastructure for something like a Xsan, your switch is going to be your friend. It needs to be your friend. It's really one of the most important components in the infrastructure. And the reason is, its job is to help isolate traffic from each of those individual systems in the Xsan and the individual components of your storage.

And the more parallelism and the more isolation that you get between those components, the more throughput you'll end up being able to get through the whole network. Basically, the more things bottleneck, the more things end up going through one pipe, the less total throughput and total capability that you get in your environment.

The ability for your switch to isolate is really, really important. So as you're looking at that part of your expenditure, one, you'll find out, quite shockingly, that the switch is probably going to be one of the most expensive pieces of equipment you buy. It's going to be probably more expensive than your storage. It's going to be more expensive than any one of your computers. It's certainly going to be more expensive than the software.

It is going to be something that you should be prepared that is going to be a very costly piece. And you need to think ahead about how many clients am I going to have in the environment? How am I going to put my storage together and how many different strands of fiber am I going to be running ultimately in order to be able to get the maximum amount of data through the system? You've got to do the math. Meaning, as I talked about just a moment ago, you've got to look back.

What are the clients in your environment doing? What kind of media are they working with? And how many streams of media are they dealing with? You've got to count audio. You've got to count the video. And you've got to kind of do all that calculation. And unfortunately, it's one of those things you've got to do really up front. Figure out, multiply out total data flow within your organization and figure out how much data is going to be driven through those strands of fiber back to the storage.

And where are the bottlenecks going to be? Always remember that, and this is one of the typical things that gets forgotten, is that the editors are always going to be dealing with multiple streams. And don't assume one workstation, one stream of data. The reality is that they're dealing with many streams because that's part of the creative process.

So, typically in video, you're dealing with pretty large files. You know, they're, you know, certainly many, many megabytes, if not gigabytes in size, you know, typically, depending on the media that you're dealing with. And from a perspective of impact, you're dealing with a reasonably small number of files, but a large amount of data. So, data is kind of coming in, you know, if you can think of a fire hose, you know, just a huge amount of information is coming in.

But you're not dealing with a large number of files. You're just dealing with a large amount of data. What you have to be careful of in environments like this is that typical computer usage workflow, let's say email or web files or, you know, Microsoft Word documents, these are very small files. And usually, if you look on your hard drive, there's lots of them. And the impact between those two different usage models is pretty significant.

That, you know, the SAN is actually extremely well tuned to be able to deal with large file access, lots of data coming over the fiber, but not lots of little bits of data coming over the fiber. That's not a very effective use of that particular resource. And it gets worse when you start mixing that data. And so when you factor in your planning and you're looking at your infrastructure, you know, one of the things you might, you know, think of doing is you put in a SAN environment, as, ooh, cool, I'll share everything.

Well, that may not be the wisest thing for you to do because as you start looking at all those little file things that are going on with your network, you could end up actually completely taking all the performance out of your infrastructure and doing that. And if it's appropriate for you to do that, or let's say the small files you're dealing with are photos, because those are certainly reasonably small files and you can have certainly a lot of those, what you may start thinking about doing is you could have a lot of those.

And if you're dealing with a lot of those, what you may start thinking about doing is you could have a lot of those. And if you're dealing with a lot of those, is trying to isolate that kind of material so that those large files and small files are actually kept in separate places so you can get, again, more parallelism through the process.

As you move on to the next step of first understanding just basic capacities, you want to start thinking about what things you can do to enhance your storage capability within the Xsan. Certainly one opportunity is being able to add more storage. More storage does not necessarily mean more disk space, though that's certainly one of the things you can get out of more storage.

But it's really adding more storage in terms of getting more parallel ways to be able to get to data. So it's basically more heads or more rotating platters, if you will, that can all be accessed in parallel. So in the case of what I'm referring to here in terms of adding storage, the goal here around adding storage is adding more parallelism, more ways to be able to get to that data simultaneously rather than adding more bytes that you can possibly put on the disk.

That happens to be. So that's one of the things that you can do to get more parallel. One of the other aspects of that is how you actually orient your storage. One of the opportunities is looking at spreading the load across multiple, basically multiple rotating surfaces by striping your data. So this is standard RAID behavior.

But you want to think about, again, if you take all the capacity that you're looking for, how can you possibly get as much of it in parallel across multiple devices simultaneously? And you should look at striping the information across these multiple devices as one way of being able to get there. Another way of approaching that is actually looking at segregating your data.

So if you have lots of different media within your environment that you're dealing with, there's a couple of capabilities that exist within XAN to really help you there in terms of being able to isolate that media in different ways. One is the use of affinities. Affinities are a technique for being able to effectively take a portion of the file system and tell it to put it on specific storage.

or look at the opportunity of actually using multiple volumes as a way, kind of a more coarse-grained way of being able to force material into different storage pools. And the kinds of things you want to be thinking about in terms of segregation is, again, keeping kind of the big stuff separate from the little stuff.

It's kind of an easy way to look at it because if you can take something like video, which is, again, usually a less number of files, but usually a large amount of data that gets streamed over time, and separate that from potentially smaller files that are going to be accessed more frequently, one example of that is certainly audio and video.

They have different, substantially different data rates, much smaller, much lower data rates as compared to the much larger and much bigger files. So, you can take a lot of different amounts of data. Certainly stills is another example. If you're doing an environment where you're creating, you know, video that has a lot of still material, look at keeping the still material separate from your video. That can help quite a lot.

Another thing to consider is not only the kinds of material, but how the material is used. So, if you have material that is like your, you know, stock photos or stock video that you want to have on hand that people can use for creative purposes, but they're not used very frequently. Particularly, you may have a huge amount of it, and people tend to use just little bits of it at a time. Look at keeping your stock material isolated away from your current active projects.

Current active projects tend to get a lot of change, a lot of activity, you know, against them, versus potentially stock material that may, you know, have a much lower rate of change. And being able to isolate that particular and slower media, or better yet, away from the material that's getting accessed at high rate, at high rate can have a big impact.

Another thing to look at is actually separating your projects themselves, the actual different projects that are going on within your enterprise from each other. You may have potentially five or six major projects that go on at a time, and one of the things you may want to consider is organizing your storage and organizing your infrastructure so that each of those projects are isolated from each other.

Not so much from a security perspective, but again from where it sits on the storage so you can get more parallelism. You can keep it all on one volume and use affinities as a way to be able to do this kind of thing. Basically allowing people to be able to share material and be able to see the material as appropriate, but being able to use the infrastructure of the Xsan to be able to tell it to where to put the material actually on your physical storage.

I want to take a little commercial break here and talk about redundancy. It's one of those things you want to think about here when you're dealing with Xsan that you've now gone from lots and lots of individual seats that are fully isolated to the ability now to share lots of material. It also means you have an opportunity for single points of failure.

So you should be thinking about that from the get-go. You probably don't want to take the chance of taking down your whole infrastructure because a component fails or something happens. And there's some ways to protect yourselves from that. Certainly part of RAID configuration and doing mirroring is one of the things that you should look at. There's looking at failover metadata controllers within the Xsan environment.

You can even use, particularly in small work groups, it might make sense to actually use even one of the clients as a potential failover. In that case, it's one of those things that you hope will never happen. But if it does, at least the system will fail gracefully and you won't take your whole infrastructure down. Another thing to look at is multipathing. Multipathing is basically using those two strands of fiber that are coming out the back of the computer as potentially multiple paths to be able to get to your data in case one of them fails.

And I believe one of the other sessions talked a little bit about how you can use multipathing within the Xsan. And I think that's a really good example of how you can use multipathing within the Xsan environment. Certainly one of the most important things in any situation is backup. And so backup is something you should factor in when you're doing your site planning.

And the other to consider, of course, is power protection. This is a great place to be putting battery backups or other things. So again, one of the things you want to think about as you're going through the process of setting up the environment, that you consider now that you have another opportunity for your data to be able to be used. single point of failure and look at all the places that you can protect yourself.

Moving on to security and collaboration. Dealing with multiple users in a media environment is a real plus, but there's some real challenges here. It is a lot, lot, lot harder than dealing with a basic file system server setup. I think from the get-go you should understand that as you're starting to think about how it works here, you've got to think things through a little bit more. And the reason it's more difficult is because in a typical file server setup, you're talking about someone being able to log in to a file server to get to their files and to save and retrieve their files.

As you start dealing in a multi-user media environment, you're actually having to think about the collaboration aspects of that and how you actually can share material across multiple people. If you're dealing with that in a networked file system environment, then you're... You're probably dealing with many of the same issues, but you typically don't tend to deal with that in that environment as much as you will when you're starting to deal with a shared media environment. Certainly, with Tiger being... So the supporting ACLs, access control lists, and actually... That will be an incredible benefit. Unfortunately, we don't have that right this moment.

So until then, one of the real things that you have to kind of factor into the whole process is planning. Make sure before you even... Put the first piece of fiber to a computer that you've thought this out because it's one of those things that six months into it, you're going to go, oh, my gosh. I completely forgot or I didn't think about this.

And what you almost are stuck doing is tearing it all apart and starting over again. So it's really important to actually take the time up front to actually do the planning. There's a lot of parts to deal with here when you're dealing with shared media, and we'll talk about what some of those things are.

And we've talked a bit about performance. Well, one of the big challenges is that security and performance don't always mix real well. And as you'll see, we'll get into this, they tend to collide in a couple of important ways that you can plan for and work around, but that's because you do it up front with planning.

And the other thing to think about is when you're dealing with multiple user projects where you're going to be sharing material, that again, you need to think it out a little bit ahead of time. So as you're planning for multiple users, one of the things that I consider to be an absolute must is you need to use a centralized directory server of some type. I'm not going to say which one you've got to use, but the fact is you need to make sure that you centrally manage your users in this environment.

Because as you're now dealing with ultimately Unix permissions in this system, files are going to have user IDs applied to them. And if you don't think about what the things are that are going to be assigned to those different files, what user IDs and what group IDs, then as soon as you start to deal with sharing those files, six months down the road after you've finally realized, gee, maybe I need to worry about this, you could find yourself in a lot of trouble. Because that wasn't something that you thought you could do.

And that you don't have a centralized way of managing. So it's really critical that you manage the users within an environment in some centralized way. And you need to just get over the fact that you are going to become an expert at Unix permissions. This is one of those things that, you know, in this particular situation, it's something you can't avoid. It's going to be very critical in terms, again, how you lay out your file system, how you deal with the multiple users. And you're going to have to be very careful about that.

And it's going to be a little bit more complicated than you might expect. And it's going to be a little bit more complicated than you might expect. So you need to really understand, you know, ahead of time how you want to, you know, put things together. You might want to look at putting together, you know, a site plan and kind of checklist, if you will. And look at each of the workstations within your environment.

And look at, for example, whether your, you know, how your media workstations are going to be configured in the environment. How your normal office workstations are going to be configured. So in the kind of normal office workstation environment, I wouldn't expect any big surprises. This should work as it normally does using home directories or whatever on your network attached storage or whatever solution you have.

Those particular things will probably work pretty much as you're used to. For media workstations, on the other hand, deciding whether or not there's going to be a dedicated workstation per user or whether you're going to allow them to move around within the environment is something you've got to think about.

Because in a media environment, there's a lot more than just a few preferences that go from place to place in these setups, particularly today. And I certainly think over time, this will get easier. But at the moment, anyway, this is a really complicated problem. Because as you move, if you're going to move users from workstation to workstation, usually the project, its performance characteristics, its expectations in terms of that real-time behavior, what kind of devices, graphics, et cetera, you know, can be very much tied to the workstation.

And so you're going to have to think about what kind of workstation that that project is being done on. And if you move around, you may find yourself having to redo an awful lot. The other thing is there's a lot of other material that tends to go with the projects, scratch files and render files and things like that. And as you move around from station to station, you'll find you will end up having to effectively recreate that through the process. And that can effectively slow down the usage model that people may have.

Um... You want to think about where the home directory is going to be for a given user in that environment. Because the home directory in a media environment is going to get hit a lot. That's where those scratch files tend to be put. That's usually where a lot of other cached information is kept within the system.

Unless you manually go and override and set that up for each workstation and user, they're going to end up having to, one, it's going to end up putting a lot of load back on your infrastructure. And two, you're going to end up finding out that your performance is just not what you expect it to be. Things are not working the way you expect.

One other thing to think about, too, at least right at the moment, is that the home directories tend to be... When you're dealing with an environment where you've set up a centralized file server for dealing with multiple users, the home directories are actually connected over the network. They're not connected over the fiber. And this can be very confusing. And again, I think this is one of these things that over time will change. But you'll get performance characteristics of home directory access that's network-based as opposed to fiber-based. Yes.

You also want to be thinking about how media plays into this environment. If you have globally shared stock material, permissions set up in that particular situation is reasonably straightforward. Usually you can keep all that stuff together and usually stock material is something that can be shared by all the users within an environment. But when you get to per project media, this is where your permissions issues tend to get more challenging.

And you want to think about when you're setting up projects within your Xsan environment, how you set up your directory tree, how you set up the permissions within that directory tree. Usually when you create a new project, for example, you want to make sure you create a Unix group for that project so that you have the ability of being able to manage which users actually have access. to the material within that project. And you need to do that from the get-go.

You also want to make sure that the directory tree within the project is set up appropriately with the permissions, not only for whoever the owner of that particular project is, but that the group permissions are correctly and properly set. And that the media within that project, within that directory tree, is mapped as appropriate based on the performance affinities that we talked about earlier.

And this is where it gets really complicated because you basically have this one tree of information that you're dealing with in terms of how your project's organized and a totally different structure that represents how your media is actually stored across your storage. And these are multiple dimensions that you have to factor in at once.

Because it's so complicated, he really encouraged you to actually draw a map of the projects and how they're organized over your storage. Again, not only in terms of their organized, how the user sees it, but more importantly, how they're organized in terms of the storage so that you get the performance expectations that you have.

When you get to this level, this is again where it tends to get kind of hard. Merging the needs of sharing material and the needs of being able to get performance can be rather complicated. Again, you're dealing with multiple dimensions of hierarchy here that need to be factored in.

And it's one of the things that can really help you over time is making sure that from the get-go as you're planning that you can think about putting together a consistent structure for all your projects. And I'll show you in a moment a very simplified example of this. But you really want to look at organizing your projects by performance types, by the kind of material you have, so that you have the ability later to go back in and apply the affinities that you may want to apply so you can make performance adjustments.

You may find I'm getting more and more users, the performance is going down, I need to add storage. But if you didn't organize the material well to begin with, you're going to find you have to back it all off, put it back on and restructure it. And that will take you down potentially for a few days.

The advantage of that is that you'll find again the requirements for audio and the requirements for video in terms of speed, in terms of the amount of data that's moving are pretty different. And you may be able to organize your storage appropriately to be able to give you much better performance. The good news is that if you look at organizing your projects this way from the get-go, you can reorganize your storage separately from this because the users don't need to know how your storage is organized.

They just care that if I go down and look in these particular folders, I'm going to find the stuff that I need to find. So think about it in advance so that it gives you the flexibility of being able to get your storage organized in an effective way.

I've been talking a lot about scratch data through a number of these things. And this is an example from Final Cut. Final Cut allows you, for example, to segregate a bunch of the ancillary files that tend to be involved in a project. You may typically think, oh, I'm doing a video project.

I've got certainly my Final Cut Pro document, and then I've got a bunch of video and a bunch of audio. Well, the reality is there's usually, and this is not just for Final Cut, but I think for many sophisticated media applications, a lot of other stuff that is generated as part of the process in order to get performance and in order to get the kind of visual expectations that people have.

For Final Cut, you have the ability of segregating, for example, where you're... you know, your audio from your video and where it's placed. As we talked about from, you know, a project organization standpoint, that can be helpful for affinities. You can, in this case, also manage where some of the render files, the files that are used to, you know, maybe, you know, render out, you know, complicated transitions or effects. Those are scratch files that are not necessarily critically important, you know, in terms of day-to-day, but it's important more from, you know, getting the kind of performance.

And there's places where it puts those things on the system. And Final Cut allows you to kind of, again, even segregate where that stuff is kept. You may want to keep that stuff locally. You may want to put it on a separate volume, you know, within the SAN.

And there's other caches that, in the case of Final Cut, are used where various, you know, thumbnails for pictures and other things are used, little things that are used just to make the UI and other things, you know, perform a little better. Many times, most of this stuff can be kind of kept on the local system. You, you know, don't lose anything by losing this material other than kind of the UI responsiveness typically in a given session. It's the kind of thing you probably don't want to put on the SAN because it just generates a lot of unnecessary traffic.

As you're thinking about multiple person projects, independently of the security issues and other things we've talked about, you want to look at other things to consider as well to make it possible for collaboration. Given that I think in the case of media, this is a pretty new world in terms of being able to get the kind of, if you will, completely seamless flow of collaboration between multiple users. There actually needs to be a little thought right now from the standpoint of how you lay out your projects and work in order to make it work more effectively.

As far as, you know, for Final Cut, for example, you may want to look if you've got a really big project that you're dealing with multiple people that you actually find ways to break it into sub-projects. In the film industry, they usually do 20-minute reels, for example. You know, you don't do the whole, you know, two-hour movie.

It's actually done in 20 minutes at a time, you know, little segments. You can actually break up your project into this and it makes it a lot easier to work with. And in the case of Final Cut, it's actually pretty easy to create a master project that brings all the pieces together.

Brett Halle You want to think about and make, you know, watch out for that, you know, multiple users shouldn't be modifying the actual, you know, same files. From a developer perspective, this is something that, you know, certainly we're used to in terms of, you know, CVS and, you know, other kinds of tools and facilities. There's not a lot of that kind of, you know, facilities right now in the media space.

There are some media management tools that are out there, but most tools that exist today, you know, don't handle concurrent modification. So, you know, there's a lot of things that you might expect from, you know, source code or, you know, software development, you know, multiple person projects. The multiple person project model has been very hard to get to without something like a SAN where, you know, this large media actually can be shared in a real way.

So, this is an area where there's weakness, you know, in this particular area where I think there's also a lot of opportunity. But you want to think about, you know, how does this work? You know, how to structure and organize things to avoid these kinds of collisions. Usually for media files, this isn't a problem.

Something like Final Cut Pro or Logic or, you know, the various, you know, DAWs and other, you know, digital audio workstations, other things. Most of them are, you know, non-destructive editors. The media itself tends to get modified rarely, if ever. It's usually what gets modified is the project files and the, you know, corresponding render files and things that are done. So, the good news is you probably don't have to worry too much about people modifying the same media files usually. But you need to think about it.

I mentioned early on that it's really important to consider making sure that you use a central directory service in terms of dealing with multiple users. I want to reiterate that again. It's one of those things that if you don't think about that up front, it will bite you. You'll come back later and you'll go, oops, yep, you were right. You need to think about that. The other is making sure that you can do that organization up front to enable the storage tuning later down the road. Two really important things that require some forethought.