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 Codecs, and some other projects within our Pro Applications division. I'm going to be talking today about the XAN product and how it fits into the video workflow. Although I will be talking from the perspective of Final Cut Pro, it actually is very applicable to anyone in the applications domain who's dealing with media in an XAN 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 under this category, and XAN 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 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 creative professional's view and what their expectations are. And then we're going to get into how this applies to XN environment and how shared storage and work group computing 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 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 home. the local movie theater, all of that is expected out of today's existing tools and hardware. And 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 probably are obviously not working with film directly in the computer, but taking it into some type of offline format. But many of, you know, for news gathering and for other things, you're dealing with DV-25, 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 trade-off 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. And while they may be in an environment with many different machines, today most of the media tends to be moved around via the network or by taking that little firewire drive and going from one system and doing the sneaker net thing. 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. The upside is you've got a huge amount of power that you get out of that single system because you can make a lot of assumptions about being able to use every bit of that bandwidth. The other downside to having all that media duplicated around the environment is that 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, for example, for folks who are doing maybe trailers or trying to do unreleased movies, they're trying to keep pretty tight control over that media before it gets leaked out and put on the internet. So doing that when all that media is being sneaker-netted around anyway on a FireWire drive makes it even easier to have that sneaker netted right outside the front door. And there's certainly a number of other challenges that a single system workflow has. It just really makes the processes you're working as a group very, very difficult. And that's where XAN comes in. 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 SAN 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 SAN 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 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. So the other advantage of XAIN's shared storage environment is the ability to consolidate that storage. Typically, 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. And again, avoiding having to have the large capacity storage on each of those workstations is a really big plus. 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,000 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 material 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 work group. 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. 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, you know, approach of moving media around is, you know, a big problem, you know, 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 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 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 SAN 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. And 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 trade-offs of being able to get that sharing and make sure that you don't put yourself, you know, 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. And there's, I think, a lot of challenges today in terms of dealing with collaboration. It's a real plus, but you gotta think it through ahead of time to understand what it is you wanna try and accomplish here. So let's start with performance first.

The goal in a SAN 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, you know, five-system SAN, and you're all going to, you know, some set of central storage. You know, 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, you know, are they working, are they typically dealing with in the projects that they're doing? Like I said, you know, if you're talking about something like, you know, commercials, commercials tend to be a good example where lots of streams of video, as you, you know, see these things on TV, it's all about, you know, 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. And 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 trying to get to single system performance is that in your fiber infrastructure for something like a SAN, your switch is going to be your friend, or 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 SAN 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. And 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 on 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, you know, 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, you know, total data flow within your organization and figure out how much data is going to be driven through, you know, those strains of fiber, you know, back to the storage and where the bottlenecks are 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. 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.

Another thing to factor into an environment like this is 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 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, One of the things you might think of doing as you put in a SAN environment is, oh, 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 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. Thank you.

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 sand. So certainly one opportunity is being able to add more storage. So 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 a benefit. 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 is 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 substantially different data rates, much smaller, much lower data rates as compared to the much larger and much bigger amounts of data. Certainly stills is another example. If you're doing an environment where you're creating 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 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, 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 against them versus potentially stock material that may 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 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 sand to be able to tell it to where to put the material actually on your physical storage.

One, I certainly recommend is thinking about where you're doing ingest within your facility as opposed to the less likely to change material, static material or potentially rendered material. Ingest is one of those cases where it's really important that you don't drop frames or other things through the process. You're trying to get this. It's coming in probably from that $50,000 deck or, you know, million-dollar telecine device. And it's pretty critical that you, you know, want to shorten that process for being able to get that material, you know, into digital form as quickly as possible. Again, looking at affinities as a way to isolate that so you can manage potentially bandwidth and to be able to, again, make sure that you effectively get isolation through the fiber from much of the other activity that's going on in your infrastructure. You actually want to take a moment and kind of draw out the map of your fiber, the users, and your storage, and think about in the different usage cases which lines of fiber actually get lit up, if you will, during the process.

And you'll find that as you go through that process that you're going to find places that are bottlenecks, that get lit up every time you do things. And those are places that are opportunities to look for more parallelism, where you can potentially move either workflows, people, and data around to be able to get more, again, more parallelism through your data flow. One of the things to kind of focus in here, specifically people who are looking at developing software, is that, you know, within that context, it actually is really important to make sure you enable your users to be able to have fine-grained control over the different types of data that may be dealing with and where it gets put. It's the flip side of being able to manage the storage. It's being able to allow the software to be able to segregate the data so that you can manage your storage.

And I'll show you an example of that in a little bit with Final Cut. But, you know, for those of you, you know, who are doing media applications, who are starting to think about this, look at ways to provide this kind of fine-grained control for your users. More opportunities for enhancing storage capability are thinking about where your -- the other side of the data flow. I'm assuming most of you have been to some of the other XSAN sessions and are aware that The infrastructure for dealing with the SAN is both fiber channel for the data access and an ethernet path for the metadata. The metadata is the basically file system operations aspect of the file system. That that communication path occurs over an ethernet channel as opposed to the fiber channel. The fiber channel is really designed for, again, that big packet, large data. When you're doing lots of file creation and file deletion, that's one of the cases where there's a large amount of traffic that tends to go back and forth between the client and the metadata controller, basically the server aspect in the XAN environment that basically is the arbiter of how the information is ultimately laid out on the disk. When you're dealing with video, again, big files but little numbers of them, you don't tend to do lots of metadata access. Usually it's a, I need to find where the file is. There's a real quick message to the metadata controller. Metadata controller says it's in this blocks on the storage.

And then from that point forward, the data flow typically goes through the fiber channel. When you're dealing with small files and you're doing lots of creations and lots of deletions, there's a huge amount of traffic that goes back and forth between the client and the metadata controller. And if you're doing a lot of that, particularly over a large number of clients, this is another opportunity for a bottleneck. So as we've talked about for fiber, you also need to be thinking about switches for your Ethernet. You need to be looking at isolating that particular path of the Ethernet traffic so that the metadata traffic is not interfering or getting overrun by potentially browsing the web or getting email off of your mail server connecting through a network attached storage device of some variety. So it becomes really important to think not only of your fiber infrastructure and where the data flow is, but potentially what your Ethernet traffic is within the environment. The other thing to look at on your metadata controller as you're doing more of these types of things is RAM helps a lot. The metadata controller tends to cast this kind of information. It is something that RAM will help with, and multiple metadata controllers too can help spread some of the load.

One thing to think of at large is look at keeping much of your caching activity on the local system, on the local client. A cache for is typically files that are created by an application purely for the purpose of speeding things up. Its job is to basically either pre-render material or to do something so that it doesn't have to redo that operation many, many, many times. It's one of those pieces of information that typically can be thrown away because the computer will ultimately recreate them. So by keeping them on the local system, you're not losing any important information in your workflow, and you're keeping the amount of traffic between the local machine and the rest of the infrastructure down to a minimum. The cache is really intended to be kept fairly local. So if you have potentially render files or various cache files and logs, those are the kinds of things that you really are encouraged, if possible, in some cases you can't, but if possible to try and keep these on your local system. That can really take a load off of the rest of your infrastructure. The other thing you should consider, particularly in the case, and I can speak for Final Cut, is that you should really consider keeping the project files themselves locally.

That's not the media. The media ends up getting kept on the shared storage, but the project that you're actually working on gets kept local. It's one of those things that tends to get accessed a lot. It's an example of lots of small file reads and writes. And it's one of those things that, again, isolation can help a lot with. Really, the whole goal, when you're looking at enhancing the storage capability within your environment, is finding a way to spread the load across as much of your infrastructure as you can and avoid single choke points. And that's where drawing it out, as tedious as that may be, can be really, really helpful in figuring out where those single points of access are within your fiber infrastructure or within your network infrastructure.

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 the sand, 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 SAN 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. 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 XAN 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, just 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 a 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. You know, it is a lot, lot, lot harder than dealing with a basic file system server setup. I think, you know, 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. 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 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 it, so the supporting ACLs, access control lists, 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 upfront 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 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 upfront 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 ID is and what group ID is, 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 out in front 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 really understand ahead of time how you want to put things together. You might want to look at putting together a site plan and kind of checklist, if you will, and look at each of the workstations within your environment. Look at, for example, how your media workstations are going to be configured in the environment, how your normal office workstations are going to be configured. In the 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, can be very much tied to the 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, and 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.

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, you know, 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. Again, placement of where all of the material that has to go with an individual user can really have an impact on performance. You want to think about how you're going to be doing that.

You also want to be thinking about how media plays into this environment. If you have globally shared stock material, permission 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 SAN 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. Thank you.

So one thing you might want to think about as you're dealing with storage, again, is kind of there's two dimensions to this, is how your material is structured, where you put your shared material, like your stock media, and within the various projects, how you structure it. So, for example, within each project, I would encourage you to isolate your media from the metadata, basically the project stuff, the little files. So you've got all your media isolated from all the little things that tend to go with your project. And that's things maybe like scripts or notes that you have or other small files, project files, for example, that may make up the project that you're doing. Those are the small things. And keep the media separate from that. And even within the media, looking at separating the media out by type, certainly looking at breaking out audio and video separately.

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 they 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. you 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, you know, 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 your audio from your video and where it's placed. As we talked about from 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 maybe render out complicated transitions or effects, those are scratch files that are not necessarily critically important in terms of day-to-day, but it's important more from getting the kind of performance that you expect. and there's places where it puts those things on the system. And Final Cut allows you to, 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 within the SAN. And there's other caches that, in the case of Final Cut, are used where various thumbnails for pictures and other things are used, little things that are used just to make the UI and other things perform a little better. Many times, most of this stuff can be kept on the local system.

You don't lose anything by losing this material other than 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. work. 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. So there 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.

You want to think about and watch out for that multiple users shouldn't be modifying the actual same files. From a developer perspective, this is something that certainly we're used to in terms of CVS and other kinds of tools and facilities. There's not a lot of that kind of facilities right now in the media space. There are some media management tools that are out there. But most tools that exist today don't handle concurrent modification, merging, and other kinds of things that you might expect from source code or software development, multiple person projects. The multiple person project model has been very hard to get to without something like a SAN where this large media actually can be shared in a real way. So this is an area where there's weakness in this particular area, where I think there's also a lot of opportunity.

But you want to think about 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 the various DAWs and other digital audio workstations, other things, most of them are 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 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.

So, wrapping up here, looking forward from this point, one thing that's really interesting is that with the introduction of Exxon and with just the dynamics of the market, certainly I think Apple and Final Cut and Exxon themselves are really changing the economics here. This is something that used to take hundreds of thousands of dollars of infrastructure and costs in terms of the workstations, other things that are involved, to be able to put together a shared media storage environment, to put something like a sand environment together. And the economics at this point are changing in a very dramatic way. And we've seen this, you know, certainly Apple's been through this kind of economic transition in a number of different areas before. desktop publishing, certainly video production in general. And now as we look in terms of the shared media space, I think we're going to see the similar kind of change. The economics are really going to change the market. We're going to see a lot more of this going on. There's some really interesting technologies coming in Tiger that actually are really going to help here. I think Spotlight, for example, is going to be a major, major, major plus here. As you now look at now having storage media environments where metadata can be attached to the media and it can be searched and found very quickly and effectively means that sharing mass stores of information actually becomes very feasible and very practical. And that's been one of the real challenges. Looking at things such as core audio and core video just from implications of the kinds of things we'll see in the production space are going to have another big impact as well. because there are going to be more and more people involved in the creative process as these tools become more and more approachable. You don't have to have expensive hardware to be able to do a lot of these things. The challenge, I think, as we move forward, is how to get media management more as part of this integral process.

And I think there's a real developer opportunity there, and I think something that is an obviously big hole that needs to be filled of now how do you manage the media through the workflow. And there are some good solutions out there, but bringing them down to scale at this level and to be more approachable, I think, is going to be one of the interesting opportunities. I think the other thing to factor here is just the actual workflow process itself, I think, is going to be an interesting part that this enables. That now having vast amounts of information available to many people in effectively real time at their desktops means that managing how the material gets through the creative process through multiple people and gets tracked through that process, which is beyond just media management, but actually workflow process management, is going to be another big developer opportunity, another opportunity within the space. Hopefully there are people out here who are thinking about those kinds of problems, and I'd certainly love to hear about the cool things guys are doing.