Okay, I've heard lots of debates on this, here's my opinion and I'm sure others will disagree.
I'm not a big fan of root-only volumes. I think that overall they are a big waste of space for very little gain. However, there are some good reasons to do it depending on your scenario.
1. SnapMirror. If you are SnapMirroring all of your data then it is a good idea to have your root volume on a separate volume. This allows you to offline your data volumes at will which is good for initial transfers or resynching back to a source.
2. SnapRestore. If your application or dataset makes regular use of SnapRestore..yes I've seen this in a case where customers like to snapshot a known good dataset, have their users mess with it, then SnapRestore back to the known good dataset afterwards. If this is your scenario, then yes, a root volume is a good idea.
3. Lots of vol copy'ing. If you do lots of vol copy commands in your dataset, then for the same reason as SnapMirror, the offline ability is a good one.
There may be others out there in the world, but these are the most common. But in my opinion, for the 50-60MB that /etc typically takes up, is it worth dedicating 2 36GB or 72GB drives? Maybe so, but most of my customers don't think so.
Just one geek's opinion. There isn't really a single right or wrong answer on this one.
-- Adam Fox NetApp Professional Services, NC adamfox@netapp.com
-----Original Message----- From: neil lehrer [mailto:nlehrer@ibb.gov] Sent: Tuesday, August 14, 2001 11:56 AM To: toasters Subject: boot volume with no data
are there any particular advantages or disadvantages to just having ontap on vol0 and data on other volumes? --
regards
Ideally, I'd like to see NetApp offer some dedicated media for root volumes in future systems. Just a pair of PCMCIA slots on the head, with a pair of mirrored (or WAFL'd) 1gb flash disks. Plenty of room for the small space needs of the root volume, and you don't lose the many gigs of disk space when you lose 2 x 36/72gb disks.
Seems like a simple thing to do, esp since the PCMCIA are already hot swappable, etc.
John John Stoffel - Senior Unix Systems Administrator - Lucent Technologies stoffel@lucent.com - http://www.lucent.com - 978-952-7548
Ideally, I'd like to see NetApp offer some dedicated media for root volumes in future systems. Just a pair of PCMCIA slots on the head, with a pair of mirrored (or WAFL'd) 1gb flash disks.
Does the 800 chassis still have the little slot above the fans that the 700's did? If I recall, this was for the NetCache branded boxes to run them w/o needing a storage shelf, but strapping 3 9gb's up there for root (2 + spare) would be fantastic.
Encourages ppl to have the dedicated root volume to prevent running into problems w/ snapmirror/snaprestore/volcopy, without sacrificing pricey storage shelf slots. Makes reconfiguration that much more flexible too, since you don't have to worry about the root vol having worked its way onto two of the shelves you want to yank and put somewhere else..
(I haven't looked since 5.3 days, but is there a way to 'relocate' a disk? ie, a pre-emptive replacement for juggling around layouts without jeopardizing volume integrity?)
..kg..
Hi,
I just performed a ndmpcopy on my filer. I ran an ls -lR on the original location and on the new location. The files and sizes were identical, the directory sizes differed. Anyone have any ideas why?
Thanks
Manny
mkaiser@mmcnet.com (Manny Kaiser) writes
I just performed a ndmpcopy on my filer. I ran an ls -lR on the original location and on the new location. The files and sizes were identical, the directory sizes differed. Anyone have any ideas why?
This is just the same effect that you would observe if you used "dump" piped to "restore" -- or, for that matter, ufsdump piped to ufsrestore in a traditional Unix environment.
As the directories are rebuilt by adding entries one at a time, they are naturally compacted. The original directories may have had unused space, particularly in filing systems like WAFL in which directories are never shrunk.
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.
Hi,
I just performed a ndmpcopy on my filer. I ran an ls -lR on the original location and on the new location. The files and sizes were identical, the directory sizes differed. Anyone have any ideas why?
Thanks
Manny
Manny, was the directory smaller or larger?
If it was smaller, then I think you are seeing the effect of NDMPcopy shrinking directories down the size they currently need to be -- not keeping them as big as they ever were.
For example, let's say that you once had a directory "junk" full of tons of files. It grew to be a 72KB directory b/c of those entries.
Then, one day you deleted a bunch of those entries because you decided to re-structure, cleanup, or whatever.
Well, now your directory may have one entry in it, but it still says it is 72KB in size.
Well, when you NDMPcopy that directory, we will create a new directory "junk" that has just the one entry in it. So the directory will only be 4KB, not a 72KB directory with all the unused entries in it.
(Another way to achieve this effect would be: 1) mkdir new_dir 2) mv junk/* new_dir/ 3) rmdir junk 4) mv new_dir junk )
If the directory was larger, perhaps the restore_symboltable file was _just_ the entry needed to push the directory from (n * 4KB) to ((n +1) * 4KB)) ?
Stephen Manley DAM and NDMP Pop Tart
-
Chris Thompson -
Fox, Adam -
John Stoffel -
kevin graham -
Manny Kaiser -
Stephen Manley