wasn't the main reason to seperate out Vol0 from the data volumes due to WAFL_iron or WAFL_check runs? my understanding was that during the run the aggregate was unavailable and since the root volume is now contained in that aggregate, with the data, the entire system is now unusable for the run time.
but, if you had a separate root volume and a data volume needed a run, the other aggregates were still accessible. I do agree that its a waste of space though. and i also agree the risk is small. But i prefer completely informed decisions.
Am I off base here? or is this old thinking?
Re: Aggregate size for small scale implementations
The consideration is storage utilization versus the very small risk of corrupting the aggregate WAFL file system.
From the Data ONTAP 'Storage Management Guide' (p 164):
The following are additional facts and considerations if the root volume is on a disk shelf: • Data ONTAP supports two levels of RAID protection, RAID4 and RAID-DP. RAID4 requires a minimum of two disks and can protect against single-disk failures. RAID-DP requires a minimum of three disks and can protect against double-disk failures. The root volume can exist as the traditional stand-alone two-disk volume (RAID4) or three-disk volume (RAID-DP). Alternatively, the root volume can exist as a FlexVol volume that is part of a larger hosting aggregate. • Smaller stand-alone root volumes offer fault isolation from general application storage. On the other hand, FlexVol volumes have less impact on overall storage utilization, because they do not require two or three disks to be dedicated to the root volume and its small storage requirements. • If a FlexVol volume is used for the root volume, file system consistency checks and recovery operations could take longer to finish than with the two- or three-disk traditional root volume. FlexVol recovery commands work at the aggregate level, so all of the aggregate's disks are targeted by the operation. One way to mitigate this effect is to use a smaller aggregate with only a few disks to house the FlexVol volume containing the root volume. • In practice, having the root volume on a FlexVol volume makes a bigger difference with smaller capacity storage systems than with very large ones, in which dedicating two disks for the root volume has little impact. • For higher resiliency, use a separate two-disk root volume. Note: You should convert a two-disk root volume to a RAID-DP volume when performing a disk firmware update, because RAID-DP is required for disk firmware updates to be nondisruptive. When all disk firmware and Data ONTAP updates have been completed, you can convert the root volume back to RAID4. For Data ONTAP 7.3 and later, the default RAID type for traditional root volume is RAID-DP. If you want to use RAID4 as the raid type for your traditional root volume to minimize the number of disks required, you can change the RAID type from RAID-DP to RAID4 by using vol options vol0 raidtype raid4.
Given the larger drive sizes we have these days and max sized aggregates as the norm I'd be more
worried about my data being unavailable than the root volume. An alternative I've discussed in classes
is to create an alternative root on a second aggregate that could be booted off of...
For protection against a wafl_iron scenario being painful you may also wish to review an earlier
discussion regarding aggregate snap shots and snap reserve:
Is there really a need to have two spares per disk type for this implementation based on best practice or is have 1 ok.
Also, since this filer is not in production I will have some time to test the different configurations. Is there any benchmarks to refer to for comparison of disk write speeds for a mounted nfs export?
I do know there are many variables like iops,cpu,network,raid,... can produce different results, I would like to get some ballpark numbers calculated.
For instance, of the GigE theoretic 125MB/s network throughput, how does ~80MB/s using dd rank?