Neil, et. all:
Separate root volumes are a good idea, its just that the NetApp architecture makes them tough to do right.
For all of the reasons listed already, separate root volumes definitely increase a filer's flexibility. The problem is that ONTAP wasn't designed with that in mind - remember, they originally only had one volume. Furthermore, it is a *very* costly decision to burn 2 shelf bays and two disks on a root volume. Some way to avoid that opportunity cost would be nice (head built-in drives, etc).
I don't agree that smaller disks (9GB or whatever) should be used for root volumes. Root volumes can't just be 100MB because of saved core files and possible future enhancements. Sometimes we've had many (i.e. up to 10) on there for good reason. With 3GB of RAM, this eats up disk pretty quick - even with the built-in compression. Besides, NetApp may want to start packaging more software on the filer in which case the root volume is a great place for it to go. Beyond just size, anyone who has managed filers with multiple sizes of disks knows that its a pain!
On a side note, someone brought up a topic about boring volume names (vol0) which I think is a fantastic segue into the inflexibility of multiple volumes. Those of you who remember the single volume days would surely agree that filer administration was *much* simpler back then. Now that we can cram more and more onto a machine and are forced to use multiple volumes, things are becoming difficult. Specifically:
1) Volumes can't be shrunk. This makes it difficult for a volume to be owned by one department because that organizations storage needs will change dynamically over time, but their disk space can only go up.
2) A corollary of item #1 is that SnapMirror and vol copy move empty space as well as used making volume consolidation or fragmentation very difficult without purchasing more disk.
3) Moving things between volumes requires us to update NFS automount maps and then coax NFS clients to re-mount the filesystem. NFS re-mounting is a pain in the butt. This also affects CIFS shares to a degree, but at least they can be centrally managed.
4) Volume inflexibilities make the decision to use separate root volumes a debate. If not for those problems, it would likely be an inarguable "yes".
5) Only 254 qtrees per volume are allowed. This is highly inflexible for those of us who use qtrees extensively and will soon start causing people difficulties. Because of aforementioned resizing problems, this could be a real bear.
Obviously multiple volumes (file systems) solves a number of technical objectives for ONTAP and I wouldn't say they need to go away. It would be nice though if NetApp could shield us from the inflexibilities. Here are some suggestions:
1) Per-qtree vol copy and SnapMirror. I can't imagine anyone who doesn't at least want this right now, let alone is dying for it.
2) Shrink-able volumes. It isn't impossible, its just not easy. =)
3) "ONTAP volume magic" which preserves all multi-volume benefits, but gives me just one path to export stuff from. This will make lots of data re-shuffling nightmares go away. Don't ask me how you'd do it!
4) More qtrees per volume - dare I say, an infinite number.
5) "Volume Locking" - that is, preventing the inadvertent configuration change of a volume. Someone mentioned accidentally adding a disk to their root volume. What if we could do a "vol lock <volname>" or something to prevent it from being added to? Sounds silly, but with ONTAP's "root or nothing" access levels, it would be a welcome bit of security.
Anyhow, sorry to ramble - just haven't posted in a while and this debate is very fresh in my mind from our recent decision to go with separate root volumes. =)
-- Jeff
-- ---------------------------------------------------------------------------- Jeff Krueger, NetApp CA E-Mail: jeff@qualcomm.com Senior Engineer Phone: 858-651-6709 Storage Lead (NAS/SAN) Fax: 858-651-6627 QUALCOMM, Inc. IT Engineering Web: www.qualcomm.com
On Tue, Aug 14, 2001 at 11:55:44AM -0400, neil lehrer wrote:
are there any particular advantages or disadvantages to just having ontap on vol0 and data on other volumes? --
regards