Stephen,
That aspect has been previously covered in this thread, albeit not in as much detail.
If one ones to get involved in all the possible issues we can talk about volume options like no_atime_update and minra, but I think it's well understood here that the discussion is about using vol0 for regular network file serving, not for application/database data storage.
-----Original Message----- From: Stephane Bentebba [mailto:stephane.bentebba@fps.fr] Sent: Friday, 14 February 2003 7:38 PM Cc: toasters@mathworks.com Subject: Re: using vol0 / consolidation
Having a separate dedicated volume root (vol0 or something else) is usefull in the Disaster Recovery procedure. By example for any kind of databases (oracle or exchange ....) .
First, because there is a different consistence point for Ontapp files (/etc, but also mbr's - what startup the Ontapp at Filer boot time) and database files. Just to make this idea clear, imagine you upgrade Ontapp, and reboot the Filer. Then relaunch the database service which suddenly crash due to corupted files. How would you recover the state before the failure.
Second, it facilitates migration. A file server generally has its own life and not always stay in a fixed place, with a fixed amount of disks, or fixed clients connected to.Having a volume for db files apart of root volume allows you to move db files to another Filer for example, or facilitate operations like mirroring (what is the need to get /etc in a database consolidation plan).
Taking a look at documents related to "Creating backup vfilers for disaster recovery" is a way to understand this interest more about that.
Clawson, Simon wrote:
The only benefit as I see it to having the smallest possible vol0 is recovery time. You can back up and recover the small amount of data in a few minutes on most tape devices, meaning you are up and running fairly quickly in the event of losing the volume.
However, there are methods of replicating the /etc data to another volume, then telling the filer to boot this as vol0. This would of course mean any NIS maps etc are broken until you change their paths, but the filer would be up and running quicker than if you were to have to restore the whole root volume first, and you would not be using two 72Gb disks for 40mb of data.
-----Original Message----- *From:* Alan McLachlan [mailto:amclachlan@asi.com.au
mailto:amclachlan@asi.com.au ]
*Sent:* 13 February 2003 01:29 *To:* Charles Bartels; toasters@mathworks.com *Subject:* RE: using vol0 Hi Charles, Don't understand why you're asking this. In most cases that I'm aware of vol0 is used for data. In some cluster scenarious, particularly with local or remote syncmirror, it becomes necessary to burn two disks to have a root volume that's just for the filer's config files - usually only on one half of the cluster. I can't imagine apart from that why someone would want to consume two whole drives for the 40MB or so of data in the /etc directory. In fact, many of my customers have only configured a second volume in order to support a database. User home directories and workgroup data stay on vol0. You should of course make use of qutoa'd qtrees within vol0 extensively to prevent it filling up - theoretically this could cause a panic in some circumstances although Data OnTap is much more robust than a Unix or Linux in this regard.
---------------------------------------------------------------------------- ---------------------------
On a related note, one issue that crops up from time to time is that when a filer is used to replace a bunch of Windows fileservers on a large CIFS network, it can happen that well-meaning Domain Admins that don't directly look after the filer and aren't trained in Data OnTAP may accidently corrupt config files in the /etc directory. It would be nice to restrict access to just a select group of trained admins. Using a Windows domain group is not the answer, as any Domain Admin can take ownership of the resource. A solution is to turn the /etc directory into a unix security style qtree: * make a new qtree called say "etcnew" * copy the files from /etc to /etcnew * rename /etc to "etcold" * rename /etcnew to "etc" * set the security style of etc to unix This works even if you only have a CIFS licence. You should then install ssaccess on a workstation to manage the security on the /etc qtree. Then, in the usermap.cfg file in /etc put an entry for each trusted admin like so: *\root => nobody (security defensive
entry)
DOMAIN\fred => root DOMAIN\wilma => root As the final step, set *options wafl.nt_admin_priv_map_to_root *to OFF. The result is that, in the example above, only the domain users "fred" and "wilma" can make changes to the /etc directory. For all the other resources on the filer (which have NTFS security style), normal domain security rules apply. -----Original Message----- *From:* Charles Bartels [mailto:cbartels@openharbor.com
mailto:cbartels@openharbor.com ]
*Sent:* Wednesday, 12 February 2003 3:45 AM *To:* toasters@mathworks.com *Subject:* using vol0 Hi, I'm configuring an F810 and space is going to be a little tight. How do people feel about adding disks to vol0 and using that instead of creating a whole separate volume (and burning a another parity disk) ? -Charles Bartels **** ASI Solutions Disclaimer **** The material transmitted may contain confidential and/or privileged material and is intended only for the addressee. If you receive this in error, please notify the sender and destroy any copies of the material immediately. ASI will protect your Privacy according to the 10 Privacy Principles outlined under the new Privacy Act, Dec 2001. This email is also subject to copyright. Any use of or reliance upon this material by persons or entities other than the addressee is prohibited. E-mails may be interfered with, may contain computer viruses or other defects. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments. **** END OF MESSAGE ****
**** ASI Solutions Disclaimer **** The material transmitted may contain confidential and/or privileged material and is intended only for the addressee. If you receive this in error, please notify the sender and destroy any copies of the material immediately. ASI will protect your Privacy according to the 10 Privacy Principles outlined under the new Privacy Act, Dec 2001.
This email is also subject to copyright. Any use of or reliance upon this material by persons or entities other than the addressee is prohibited.
E-mails may be interfered with, may contain computer viruses or other defects. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments. **** END OF MESSAGE ****