are there any particular advantages or disadvantages to just having ontap on vol0 and data on other volumes?
nlehrer@ibb.gov (neil lehrer) writes
are there any particular advantages or disadvantages to just having ontap on vol0 and data on other volumes?
Well, an obvious *disadvantage* is that it uses up at least two discs to have a root volume that contains nothing but the ONTAP operating system. When I first started reading the toasters postings, I was amazed to find that there were people out there who seemed to think nothing of wasting discs like that ... :)
Another question: why do so few people change the *name* of their root volume from the utterly boring "vol0"? I put that one down to lack of imagination ... :)^2
Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.
On Tuesday, August 14, 2001 18:00:02 +0100 Chris Thompson cet1@cus.cam.ac.uk wrote:
Another question: why do so few people change the *name* of their root volume from the utterly boring "vol0"? I put that one down to lack of imagination ... :)^2
I can think of several reasons to use the 'boring' vol0. One advantage to sticking with default names is that there is less chance for error when you're working on a system at 5AM Sunday after two hours sleep. The fewer translations you have to do between the documentation and your system the less likely you are to screw something up. Giving descriptive names usually come back to bite you. Name your volume something like 'temp' or 'new_data' and later on you'll get another filer or a new shelf and want to relocate the files but won't be able to easily relocate the name. Any time more than one person is involved, there will be disagreements on what to name something. Also, the shorter the name, the easier it is to type and the harder it is to mispell.
Or it could just be laziness or lack of imagination...
Frank
-- Frank Smith fsmith@hoovers.com Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
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
Jeffrey Krueger wrote:
- Shrink-able volumes. It isn't impossible, its just not easy. =)
This is something I would *really* like. You don't need it often, but when you do...
I have a filer with a volume > 1.5TB that I can't upgrade because volumes > 1.5TB cause a halt on boot in the latest versions of ONTap. (By my counting the volume was 1.33TB, but NetApp didn't mention before that it was counting raw sizes including parity disks.)
There could be two methods for removing disk: A) Removing 1 disk or B) Removing entire raid group. Removing an entire raid group might be simpler, but it could require a few spare disk (you might have to grow a volume before you had space to remove an entire raid group).
It seems to me that shrinking volumes by removing 1 disk could be done by a 6 stage process: 1) Mark the last drive in the volume as full (i.e. Read Only) 2) Find files with data on that disk 3) Rewrite those files (this could be done by clients rather than the filer) 4) Wait for snapshots with data on this disk to be deleted. 5) Write zeros to the data area of the disk (to ensure the parity is correct after removal) 6) Final tidy up and marking disk as spare.
This could all take some time, but a process that takes a week would be much better than 5 days downtime while I backup and restore my data.
Is NetApp likely to be able to shrink volumes in the near future?
- Bruce
-- Bruce Arden arden@nortel.com Nortel, London Rd, Harlow, England +44 1279 40 2877
arden@nortelnetworks.com (Bruce Arden) writes
[...]
It seems to me that shrinking volumes by removing 1 disk could be done by a 6 stage process: 1) Mark the last drive in the volume as full (i.e. Read Only) 2) Find files with data on that disk 3) Rewrite those files (this could be done by clients rather than the filer) 4) Wait for snapshots with data on this disk to be deleted. 5) Write zeros to the data area of the disk (to ensure the parity is correct after removal) 6) Final tidy up and marking disk as spare.
This scheme is remarkably similar to the procedure used for vacating the disk blocks needed for zone checksums in a 5.x -> 6.x upgrade. That suggests that it is feasible, at least in principle.
It would be highly undesirable to have clients involved in step (3), and there's no need. Nor need whole files be moved: only the blocks actually allocated on the deprecated disc(s) need to be marked as "dirty" internally to the filer, so that they get reallocated on undeprecated discs.
Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.
I prefer to have my root volumes separated from the data volumes. For one, this helps to keep the root volume from becoming 100% full. In the even a root volumes becomes 100% full, a filer may simply reboot or all out panic. Before anyone tells me how remote that chance is, I have dealt with those consequences already. It is more of an annoyance then a real problem but the separation of root volumes provides me with one less thing to worry about.
I must agree with all of the others reasons as well as they were so well put. If one were inclined, the cost is easily justifiable in larger shops but I will admit in smaller installations such justification may be harder to come by.
Number of disks required to store a core dump
When the filer creates a core dump, it saves the contents of the memory and NVRAM to a set of fixed-sized areas at the beginning of all the disks. Therefore, you must make sure that the filer has enough disks to create a complete core dump for a given size of memory and NVRAM.
For DOT version 6.0.1 here are NetApp recommendations for the minimum number of disks that must be installed for a filer to successfully perform a core dump is shown in the following table.
Memory 4-GB 9-GB 18-GB 36-GB 72-GB NVRAM disks disks disks disks disks
512MB 32MB 6 3 2 2 1
1GB 32MB 12 6 3 3 1
3GB 128MB n/a 18 9 7 2
as pulled directly from the DOT 6.0.1R3 Start Here document, Chapter 2: Information for All Users, System requirements for this release of Data ONTAP.
neil lehrer wrote:
are there any particular advantages or disadvantages to just having ontap on vol0 and data on other volumes? --
regards
On Tue, 14 Aug 2001, neil lehrer wrote:
are there any particular advantages or disadvantages to just having ontap on vol0 and data on other volumes?
...glancing at the 880 info today, I noticed:
"An integrated CompactFlash boot device simplifies management in remote or multifiler environments"
Does this effectivley replace the root volume? If so, is it automagically mirrored to a cluster partner's compactflash for failover? (since an ATA disk wouldn't be visible by both heads).
Nice going.
..kg..
...glancing at the 880 info today, I noticed:
"An integrated CompactFlash boot device simplifies management in remote or multifiler environments"Does this effectivley replace the root volume?
No, it replaces the boot areas on all of the disks; it doesn't contain any of the configuration information that appears in, for example, files under "/etc".
-
Bruce Arden -
Chris Thompson -
Frank Smith -
Guy Harris -
Jeffrey Krueger -
kevin graham -
Mr. G. D. Geen -
neil lehrer