This is very interesting. The last time I set up two new filers I
specifically asked Netapp if there was a good reason I should have a
separate aggregate for the root vol and was told that for most
situations Netapp recommends a single large aggregate per filer.
Of course, I've never actually needed to do a wafl_check on any of my
filers yet (after about 10 years), which I guess makes it a rare
concern, but if I ever did that could be a real issue.
--
Michael W. Sphar - IS&T - Lead Systems Administrator
SMBU Engineering Support Services, BMC Software
-----Original Message-----
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com]
On Behalf Of Kennedy, Jeffrey
Sent: Sunday, September 09, 2007 3:48 PM
To: Alan McLachlan; toasters@mathworks.com
Subject: RE: No spare disks for root
The primary reason for a separate root volume is wafliron and waflcheck.
Doing a wafliron/waflcheck on the root volume requires the filer to be
offline in maintenance mode. So if you're root volume is your data
volume, and your data volume is TB's in size, you will be offline for a
long time.
However, if you have a separate root volume, once that 2 drive volume is
checked the filer can come online and the data volume(s) can be ironed
online.
This applies to a root flexvol being on a large aggregate as well. That
aggregate cannot come online until the entire aggregate is
checked/ironed if it contains root.
Jeff Kennedy
QCT Engineering Compute
858-651-6592
> -----Original Message-----
> From: owner-toasters@mathworks.com
[mailto:owner-toasters@mathworks.com]
> On Behalf Of Alan McLachlan
> Sent: Wednesday, September 05, 2007 5:19 PM
> To: toasters@mathworks.com
> Subject: RE: No spare disks for root
>
> Hi Mike,
>
> Agreed - but this can be avoided with judicious use of quota
management
> - hence my comment"Any other issues are about configuration
> and administration and are easy to deal with if you know what you're
> doing."
>
> Having all CIFS shares and/or NFS exports coming from withing quota'd
> qtrees is something I would tend to do and recommend anyway, along
with
> SNMP traps for warning thresholds etc., but admittedly it only takes
> someone to slack off and start putting data outside those qtrees and
> then you do run the risk of a full rootvol. Hence why a small FlexVol
> dedicated to root is the way to go if you're able to run newer
versions
> of OnTap.
>
> Unfortunately in the situation under discussion it's an old F760 with
a
> pre-7 version of version of OnTAP and no support contract therefore no
> way to (legally) upgrade the OS.
>
> Regards,
>
> Alan.
>
> _____________________________________________
> From: "Sphar, Mike" [mailto:Mike_Sphar@bmc.com]
> Sent: Thursday, 6 September 2007 2:51 AM
> To:
toasters@mathworks.com
> Subject: RE: No spare disks for root
>
> I certainly had many many years of filers sharing data on the root
> volume as well, but I would point out that one danger with that is
> sometimes running out of space on the root volume can do Bad
> Things(tm).
>
> I agree though that if I had an already production system serving data
> sharing the root volume I wouldn't go into panic mode over it, but if
> I
> had the freedom to start over and do it "right", I probably would.
>
> Though still, if I was starting over I'd prefer to upgrade to a
> version
> of the OS that supports flexvols, and then use a small root flexvol.
>
> --
> Michael W. Sphar - IS&T - Lead Systems Administrator
> SMBU Engineering Support Services, BMC Software
>
> -----Original Message-----
> From: owner-toasters@mathworks.com
> [mailto:owner-toasters@mathworks.com]
> On Behalf Of Alan McLachlan
> Sent: Tuesday, September 04, 2007 11:52 PM
> To: toasters@mathworks.com
> Subject: RE: No spare disks for root
>
> Hi Coolhand,
>
> Why do you feel that having the small amount of root info in the /etc
> directory in the same volume as your data is a problem?
>
> Having all the disks on the root volume isn't really a problem. I
> installed many filers in the days before NetApp started recommending
> people dedicate two disks for the root volume, and never had any
> issues
> with using the root vol for data. In fact most of my customers for
> five
> years or so when I worked as an SE for a NetApp reseller user vol0 for
> data such as user homedirs and workgroup directories and no-one even
> really thought about it.
>
> A second volume is needed only where you want to change volume level
> options ("minra", "noatimeupdate" etc), or have a separate volume for
> database tablespace files or iSCSI/FCP LUN's. Qtree quotas can deal
> with
> most space restriction requirements. Also you will want multiple
> volumes
> if you're doing bare-metal backups ("snapmirror to tape") or DR
> replication for application data volumes with differing RTO's/RPO's.
>
> The only real advantage to be gained by dedicating disks for the root
> volume in earlier versions (before Ontap 7 with FlexVols with it's
> obvious additional benefits) is that the disks for a dedicated
> non-root
> data volume can be moved as a set to another filer and that data
> volume
> is then available on the second filer as a foreign volume without
> having
> to do extra steps after boot. Any other issues are about configuration
> and administration and are easy to deal with if you know what you're
> doing.
>
> The obvious major disadvantage to dedicating two disks for the root
> volume is the vast waste of storage space* at least in Ontap 7 with
> FlexVol you can have a dedicated root vol for administrative
> separation
> purposes without wasting space, although you now if you move physical
> disk sets all volumes in the same aggregate are visible on the filer
> you
> move the disks to.
>
> The administrative issues you mentioned are easily fixed. Just rerun
> CIFS setup and reconfigure to give yourself access. Or if you don't
> want
> to change an existing domain configuration you can modify the security
> information in /etc via the "rdfile" and "wrfile" commands with
> cut-and-paste, i.e. add the SID for the windows user to the
> "Administrators" group in lclgroups.cfg and/or add a mapping for the
> Windows user to "root" in usermap.cfg.
>
> Another thing to check is the security style on the volume and the
> permissions on the /etc directory.
>
> One handy thing to do is make the /etc directory a qtree:
>
> Filer> qtree create etcnew
>
> Copy the contents of /etc to /etcnew
>
> Rename /etc to /etcold (from Windows)
>
> Rename /etcnew to /etc
>
> Then you can delete the /etcold directory or keep it there for a
> backup.
>
> The advantage of doing this is it allows you to separate out /etc for
> quota management purposes. Also, for a CIFS-only filer in a large
> domain
> environment where you want to restrict access to /etc to only specific
> filer admins you can set the security style on /etc to "unix" then
> create mappings to "root" in usermap.cfg for specific Windows admin
> accounts while locking the rest of the "domain admins" out of /etc.
> You
> can edit the UNIX permissions on the new /etc qtree using the free
> SecureShare Access". I've done this on a couple of CIFS-only sites
> where
> they had lots of domain admins but wanted only specifically trained
> filer admins to have access to /etc and it works a treat.
>
> Hope this helps. If you need any more information send me an email to
> my
> personal address, AlanMac"at"technologist.com
>
> ^ (to avoid spambots when this post goes to the toasters archive web
> page)
> Regards,
>
> Alan McLachlan
> Technical Consultant
> EBM-2 Project
> Queensland Health
> Ph. +61 7 31311618
> Mobile +61 428 655644
>
>
>
> _____________________________________________
> From: coolhand2120 [mailto:tony@claydesign.com]
> Sent: Wednesday, 5 September 2007 9:34 AM
> To:
toasters@mathworks.com
> Subject: No spare disks for root
>
>
> I have a netapp F760 with 4 FC shelves, because I'm ignorant of how
> these
> things work I added all my disks (28x72gb) to my root volume. Now I
> have no
> spare disks, and no room in any shelf to add disks. What do I do?
>
> I don't care about the information on the filer, I just want a root
> volume
> with 2 disks! I promise not to use all the disks on a single root
> volume
> again! I have a /etc directory on a NFS host. I don't have NFS
> license
> though so I can't copy files onto the filer via NFS, I have a CIFS
> license
> but for some reasons it says "access denied" when a CIFS client tries
> to
> access it.
>
> I have console access and telnet access, I'm so frustrated I took the
> filer
> home so I have physical access. I don't however have a support
> contract
> with netapp or an account on their site (pending their review of my
> application). I can't create any new volumes because all the disks
> are
> assigned to the root volume vol0. Is there anyway to fix this?
>
> -Coolhand2120
> --
> View this message in context:
>
http://www.nabble.com/No-spare-disks-for-root-tf4380728.html#a12487751
> Sent from the Network Appliance - Toasters mailing list archive at
> Nabble.com.
>
>
>
> *****************************************************************
> This email, including any attachments sent with it, is
> confidential and for the sole use of the intended recipient(s).
> This confidentiality is not waived or lost, if you receive it and
> you are not the intended recipient(s), or if it is transmitted/
> received in error.
>
> Any unauthorised use, alteration, disclosure, distribution or
> review of this email is strictly prohibited. The information
> contained in this email, including any attachment sent with
> it, may be subject to a statutory duty of confidentiality if it
> relates to health service matters.
>
> If you are not the intended recipient(s), or if you have
> received this email in error, you are asked to immediately
> notify the sender by telephone collect on Australia
> +61 1800 198 175 or by return email. You should also
> delete this email, and any copies, from your computer
> system network and destroy any hard copies produced.
>
> If not an intended recipient of this email, you must not copy,
> distribute or take any action(s) that relies on it; any form of
> disclosure, modification, distribution and/or publication of this
> email is also prohibited.
>
> Although Queensland Health takes all reasonable steps to
> ensure this email does not contain malicious software,
> Queensland Health does not accept responsibility for the
> consequences if any person's computer inadvertently suffers
> any disruption to services, loss of information, harm or is
> infected with a virus, other malicious computer programme or
> code that may occur as a consequence of receiving this
> email.
>
> Unless stated otherwise, this email represents only the views
> of the sender and not the views of the Queensland Government.
> ****************************************************************