The answer, of course, depends on what you are using the filer for. Here are a few things to consider.

A volume may have multiple raid groups, but you cannot put multiple volumes in one raid group. A raid group is at least 2 disks (1 data and 1 parity), so a volume is at least 2 disks. Having lots of small volumes wastes disk storage. Furthermore, you must export or share volumes separately. If your clients need to access files on all the volumes, then each client must mount or attach each volume separately.

You don't need separate volumes for separate projects or departments because of quota trees. You can put each project in its own quota tree to control how much disk space the project can use. You can also impose disk quotas on individual users, and you can give one user different quotas within different quota trees, etc. Some configuration parameters, such as security style, operate at the quota tree level.

You can easily change the size of quota trees. You can enlarge volumes by adding disks, but you cannot shrink a volume without destroying it first.

So you could easily have one huge volume on your filer and be just fine, but there are reasons for not letting one volume get too large, and there might be other reasons for multiple volumes.

Snapshots are a volume level operation. You cannot snapshot a directory or a qtree, only an entire volume. Snapshots use disk space depending on the "churn rate" of the volume. Personal user files do not change often, but are precious, and should be snapshotted often. Large scratch files change very often, and usually do not need to be backed up at all. Snapshotting these files is a big waste of space. You may need different volumes with different snapshot strategies.

There are a large number of configuration options that apply at the volume level. Different volumes can be configured differently.

Utilities such as "vol copy", "snap mirror", and "snap restore" all operate at the volume level. You don't have to backup entire volumes, but many folks find volume backups to be the most convenient, especially for disaster recovery. Larger volumes are more unwieldy to backup.

If you ever get a double disk failure in the same raid group (unlikely, but possible) then you must assume that you will lose the entire volume. Although you have technically lost only the one raid group, the remaining raid groups do not contain a coherent subset of the volume. How long can you afford to be down if such a catastrophe occurs? The larger the lost volume, the longer it will take you to restore it from backup media.

There isn't any problem starting out with a minimal volume for the root filesystem and a separate volume for your data. In fact, I would recommend doing this when you first get your filer for playing around. Instead of adding disks to the root volume, create a second volume. You can try different config options, you can destroy it, build it back, etc.

If you go into production with a minimal root volume and a separate data volume and later on find yourself tight on disk space, you are not painted into a corner. Without disturbing any user data, you can copy over the system files to your data volume, make the data volume the new root volume, destroy the old root volume, and add those disks to the new root-and-data volume.

So, we are looking at getting a 720 (possibly a used 740) in the near future. How should I configure it wrt number of volumes and so forth? Is there a FAQ somewhere where I can read about the theory behind volume configuration?

Basically, I've seen posts that make me think it might be nice to have one volume just for the root filesystem, and another for the actual data we'll be using. What are the restrictions on volumes and so forth? Can I have a 2 volumes in a RAID set, or no?

I'd just like a pointer towards a FAQ, when you come down to it, I realize these questions are quite vague. :)

Thanks, Jordan

Steve Losen scl@virginia.edu phone: 804-924-0640

University of Virginia ITC Unix Support