2013-12-04 11:46 AM
I wanted to migrate vol0 to another aggregate on a FAS2040 running 8.1.3. When I went to mark the new volume as root, I got this:
controller1> vol options vol0_new root
vol options: Volume 'vol0_new' cannot become the root volume after a reboot because it must be at least 132 GB on this appliance.
The root volume really has to be 132 GB to hold 5 GB of data?
Sirius Computer Solutions
2013-12-05 10:32 PM
Hi Russel Bass,
The root volume must have enough space to contain system files, log files, and core files. If a system problem occurs, these files are needed to provide technical support. It is possible to create a FlexVol volume that is too small to be used as the root volume. Data ONTAP prevents you from setting the root option on a FlexVol volume that is smaller than the minimum root volume size for your storage system model. Data ONTAP also prevents you from resizing the root volume below the minimum allowed size or changing the space guarantee for the root volume. The minimum size for a root FlexVol volume depends on your storage system model.
Storage system model Minimum root FlexVol volume size
FAS2040 160 GB
3040 160 GB
2013-12-05 10:37 PM
I fully understand that. I still think it is way too large for some of these units. Hard to tell a customer they are losing that much space.
Russ Bass | Sr Storage Solutions Engineer
Direct: 210-918-9596 | Cell: 612-508-7774
Sirius Computer Solutions | www.siriuscom.com
7760 France Avenue S, Suite 1310, Bloomington, MN 55435
2013-12-06 01:32 AM
That is right..customers usually dont want to give away 100-200 GB of space for root volume.But they have to convinced saying that these hold the most important configuration files for the filer to operate.Also they have to accomodate a number of core files that may be generated over a period of time (each core going upto 5 GB in some cases).Most importantly be sure to set the guarantee of this volume as VOLUME to reserve space for it.Thinning it is not a good practice though the customer might insist on that.
2013-12-16 10:55 AM
I am a customer, and I don't like giving away any space. That's me, not a generality. Thin provisioning to the hilt until I can buy more space, or migrate to another storage system.
But telling me that empty space thick-provisioned as a reserve is "important configuration files for the filer to operate"? That's a beyond misleading, and a bit insulting. If you need 160GB for configuration files, you're doing something wrong. (That is a generality, but hopefully one we can agree on.)
Are these process dumps or OS dumps? At 5GB each, that sounds like the whole system, not just a process map?
You could explain to the customer what core dumps are, how they help troubleshoot crashes, and how often NetApp uses them. Of course, if NetApp never downloads core dumps for analysis, you should also have a good explanation why the customer gives up space for this best practice spec.
So, my math may be wrong, but 160GB of a RAID6 over 11 spindles of 600GB is ~3-4% of my useable space. Not insignificant. Equivalent to 2-5 Windows VMs, depending on de-dupe savings. Then, repeat on the other controller.
2013-12-19 04:02 AM
Note that you can get your answer only from Netapp Engineering why they have mentioned 160 GB of space for filer models.
As a administrator or storage consultant - my aim to ensure that the system doesnt crash due to lack of space ..especially on the root file system which is controlling my filer operations