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 ****