You’ll need pre-shared keys setup (as ever), but the rest is prompted for. There’s no data validation (no surprise). The script will output 4 text files, one for creating/restricting all the volumes, one for the “snapmirror.conf”, on to be used in place of “snapmirror.conf” while you are doing the baseline initialization, and finally one to actually initialize the snapmirrors. There’s no intelligence around concurrent streams, so initialization is still a bit of a juggling act and waiting game.

Please let me know if you find this useful.

#!/bin/bash

echo “Please enter the name of the PRIMARY filer: ”
read PRI_FILER

echo “Please enter the name of the DR filer: ”
read DR_FILER

ConnectString=”ssh -c 3des”
#ConnectString=”rsh”

SnapMirrorHour=22
SnapMirrorMinute=0
SnapMirrorStagger=5

echo “” > ${DR_FILER}_filer_volumes.txt
echo “” > ${DR_FILER}_snapmirror.conf
echo “” > ${DR_FILER}_sm_initialize.txt
echo “” > ${DR_FILER}_snapmirror_init.conf

for AGGR in `${ConnectString} $PRI_FILER “aggr status” | awk ‘$2!~/State/{print $1}’`
do
 SIZE=`${ConnectString} $PRI_FILER “df -Ah $AGGR” | sed ’s/\([0-9][KMGT]\)B/\1/g’ | awk ‘$1!~/.snapshot|Aggregate/{print $2}’`
 for VOL in `${ConnectString} $PRI_FILER “aggr show_space $AGGR” | awk ‘$1!~/Space/{print $0}’ | awk ‘$4~/volume|file|none/{print $1}’`
 do
  echo “vol create ${VOL} -s none ${AGGR} ${SIZE} ” >> ${DR_FILER}_filer_volumes.txt
  echo “vol restrict ${VOL}” >> ${DR_FILER}_filer_volumes.txt
  echo “snapmirror initialize -S ${PRI_FILER}:${VOL} ${DR_FILER}:${VOL}” >> ${DR_FILER}_sm_initialize.txt
  echo “${PRI_FILER}:${VOL} ${DR_FILER}:${VOL} – ${SnapMirrorMinute} ${SnapMirrorHour} * *” >> ${DR_FILER}_snapmirror.conf
  echo “${PRI_FILER}:${VOL} ${DR_FILER}:${VOL} – - – - -” >> ${DR_FILER}_snapmirror_init.conf

  SnapMirrorMinute=`expr $SnapMirrorMinute + $SnapMirrorStagger`

  if [ $SnapMirrorMinute -gt 58 ]
  then
   SnapMirrorMinute=0
   SnapMirrorHour=`expr $SnapMirrorHour + 1`
  fi
  if [ $SnapMirrorHour -gt 23 ]
  then
   SnapMirrorHour=0
  fi
 done
done

This isn’t something I see very often, but when I do, it’s interesting to see the stats speak for themselves. I’m with a customer who had a scripted deployment of their NetApp estate a few years ago, and it wasn’t designed or delivered with too much care or attention (something I want to discuss another day). They have a VMware estate with SQL, Exchange and other things. It all runs across a total of over 100 15k FC spindles. It’s not a huge estate in comparison with other sites, so I’m intrigued into why they have such performance issues.

Now when you run through “sysstat –u”, you can see that the filer itself is doing very little, quite happily getting on with what it should do. But the disk is hitting 100% quite often. Immediately this shows a disk problem. They need more spindles, obviously?

Firstly there is an imbalance of spindles. They have a second aggregate on the partner controller that only has test volumes. I get permission to remove this and hot, I re-allocate these to the other controller and expand the existing aggregate. This doubles the spindle count, but I know it’s not going to do anything for existing performance (in that the data won’t automatically redistribute itself!).

If I run through “stats show disk:*:disk_busy” I can see something pretty obvious. There is a single disk in the entire system that is hitting 100%, the rest are not. There are a bunch of other disks (about 10), that are running 50-60%, and then the remaining disks ticking away at around 20-30%. So what has happened here? NetApp technology should prevent any form of hot spindle in the system.

My theory is this. The filer was racked and stacked out of the box, but the aggregate wasn’t grown (3 disk aggregate, 1 data, 2 parity). Some storage was provisioned and data migrated. They ran out of space, so grew the aggregate (a little), then copied a bunch more data onto the disks. After all this, they then added the rest of the disks. Now because data won’t automatically re-allocate on the fly, any data that remains unchanged (as will happen with VM System Disks, old Exchange emails, and old Data Warehousing data), then they are still sat on the original spindles or even spindle as when they were first installed.

So I’m now looking forward to the weekend. We’ll be upgrading them to Data ONTAP 7.3.2 and I can then run some reallocation scans across the system without impacting snapshot space usage (huge bonus, thank you NetApp!). I’m hoping that this will remove the hot spindle issue. I have some before stats, and I’ll pull out some after stats next week. I’ll update this post accordingly.

Lesson from the story? Setup your storage system COMPLETELY and thoroughly before you start throwing data at it. Don’t get excited about using your new storage toy and throw data on it immediately. I have seen the above scenario on several occasions now, and prior to ONTAP 7.3, it was a pain to fix.

Quick snapshot of the stats output. Keep in mind that across a cluster this will show all disks, so all disk stats are entirely relevant. The busy disks here just don’t add up to the actual number of disks in the system, and you can clearly see the one busy disk.

> sysstat -u 1
 CPU   Total    Net kB/s    Disk kB/s    Tape kB/s Cache Cache  CP  CP Disk
       ops/s    in   out   read  write  read write   age   hit time ty util
 11%    3220  6942  3270   4232      0     0     0    12   95%   0%  -  60%
 11%    2898  7385  4030   4892      0     0     0    11   94%   0%  -  69%
  9%    3547  1820  3496   3920     24     0     0    11   93%   0%  -  89%
  7%    2329  1160  3048   3892      0     0     0    11   93%   0%  -  81%
 10%    3173  2055  4851   4644      8     0     0    11   93%   0%  -  67%
  9%    2491  1860  4547   4568     24     0     0    11   91%   0%  -  98%
  9%    2523  2960  4404   5372      0     0     0    11   90%   0%  -  89%
 14%    5136  8173  4465   3352      0     0     0    11   95%   0%  -  81%

> stats show disk:*:disk_busy
… snip …

disk:88922F61:C2026AF9:E5D68A17:B49415B1:00000000:00000000:00000000:00000000:00000000:00000000:disk_busy:51%
disk:B677DDF1:8588AAF1:D71B2CFD:3C2BB6D4:00000000:00000000:00000000:00000000:00000000:00000000:disk_busy:34%
disk:08F03F36:067E5BD0:749AF2F3:429BBEC2:00000000:00000000:00000000:00000000:00000000:00000000:disk_busy:41%
disk:54DA4952:17856AC1:22FB0FCE:A283EF92:00000000:00000000:00000000:00000000:00000000:00000000:disk_busy:57%
disk:7CD76662:56D914F1:EC90930B:EC01EC2C:00000000:00000000:00000000:00000000:00000000:00000000:disk_busy:51%
disk:2777F697:BC2DE4B1:A6967344:3FF4F607:00000000:00000000:00000000:00000000:00000000:00000000:disk_busy:46%
disk:3BC9BA7A:D0085F2E:06DF43C8:5498E687:00000000:00000000:00000000:00000000:00000000:00000000:disk_busy:0%
disk:07EBF5F5:904AEAD8:03BAC8B5:CAF1F896:00000000:00000000:00000000:00000000:00000000:00000000:disk_busy:55%
disk:03AE8BA0:8D269AF9:4FF4F01B:B5BA8B7A:00000000:00000000:00000000:00000000:00000000:00000000:disk_busy:40%
disk:326B6A85:20FA7613:86E60929:2C2559B9:00000000:00000000:00000000:00000000:00000000:00000000:disk_busy:90%
disk:EFEDE851:60FD51E3:A7D780C4:0D4E1CC0:00000000:00000000:00000000:00000000:00000000:00000000:disk_busy:37%
disk:6A89A9E3:575C15F3:E369B326:CD51EBFF:00000000:00000000:00000000:00000000:00000000:00000000:disk_busy:0%
disk:A6840DBD:8D81796E:A2E9CF67:663F9940:00000000:00000000:00000000:00000000:00000000:00000000:disk_busy:0%
disk:6D37E864:7426A291:2C946571:F96E0F84:00000000:00000000:00000000:00000000:00000000:00000000:disk_busy:54%

… snip …

This basically entails growing a stately ‘tash for the month of November in order to raise money for Prostate Cancer charity.

Please sponsor me by heading over to my Mo-Space page – http://uk.movember.com/mospace/13540

My Mo-tash after 2 weeks

Related articles by Zemanta

• Hair Today…Cancer Gone Tomorrow? Make Movember Matter! (sassholes.blogspot.com)
• Movember: Sport A ‘Stache To Support Men’s Health (huffingtonpost.com)

It’s an interesting topic, and something that I’d like to share with you at this early stage in my own project as it makes you look at the storage aspects in a different light.

What affects a piece of data’s risk class?

1.  Who has access to it?
2. How confidential is it?
3. Does it have a tangible value?
4. How portable is it?
5. Could it potentially damage the business reputation?
6. Is it protected?
7.   … probably a lot more!

Some of these are all questions we already have asked about the data sets as we need to define snapshot, replication and tape policies, but data protection goes a lot further than just this. Interestingly the Zemanta plugin for my blog has linked “data protection” with “Information Privacy”, which is a key point!

Who has access to it?

Not just from a front-end authorised point of view, although you do need to know this. Payroll for instance, generally it would just be HR and Accounting that have access to this, but is there a mechanism for anyone else to gain access to it? If so, is there any audit control to check who has been granted access, or who has gained access? The audit control is almost more important than the security in the first place. Security can and will always be broken, but if you can prove it was broken, then you can fix it!

How confidential is it?

Most of us have a fair grasp on what is confidential and what is not. Employee data, Customer data, Payroll, Accounting, are all obvious candidates for highly confidential data. But other things are still confidential, even if they are not classified as highly confidential. External IP schema’s, low level system passwords, although they may be freely accessible by the technical teams, they are not available to the secretaries for instance, so this makes them confidential in some way. Are they marked as confidential? Other than applying common sense, have you ever told anyone that they shouldn’t email a domain administrator password around for instance?

Does it have a tangible value?

Very difficult one to play and the analysts will love this! But some things have a real immediate tangible value, purchase order or a signed contract maybe. There is scope for defining a cost scoring system against data, but it is very difficult to calculate. Something will cost money in very indirect ways, for instance if something damages the company’s reputation, it could cause loss of revenue. This should really be assessed in other areas and not necessarily spend time putting a tangible value on every piece of data (I want to finish my project this year!!!).

How portable is it?

With the age of Virtual Machines, portability is very important, and very dangerous. Someone can literally just walk off with an entire database system now on a portable hard drive! How do you protect against this? Is there any way to bind key systems, or police raw access to them? As much as technology and WAN speeds have come along, it’s still fairly unreasonable to assume you could email an entire system. However it is very easy to email spreadsheets and documents around. Preventing this from happening can be restrictive on day-to-day running of a business, so we fall back to auditing and monitoring. There are a lot of bases to cover, portable media, email, file shares, etc.

Could it damage the business reputation?

This is a good one, and not something you might immediately think of. Not just necessarily “dirt” on the business, but perhaps the business has a key technology or system that means they are unique in the market. If this is leaked to another company, it could damage the reputation as others could then start doing the same. Could the business reputation be damaged if the data were absent? If a key system was offline for a period of time, how would the business reputation be damaged (take a look at some start-up Cloud companies!). A damaged reputation could sink a company. Naturally company ethics and business practices are a good way of destroying a reputation. I have many friends that still won’t buy Nestle!

Is it protected?

And this is an amalgamation of all of the above really. The questions above help you to define the business value on a particular data asset. So if it has a high value, how protected is it? How protected should it be? How long can the business survive while it is being recovered? How much would data loss actually cost the company?

Depending on the risk class and business value will greatly affect the protection and auditing you deploy around it.

Putting this into action

I’d love to hear from people about how you put the above into action. We use NetApp ourselves (definitely practice what we preach), and this gives me a great level of control over my data sets and the protection we employ. Protection goes further than just snapshots and tape backup however; we need to protect it from more than just data loss. While NetApp have some great tools for protecting against data loss, there is a requirement to help with the other areas of data protection, and I’d love to see NetApp build on this space.

I have some experience using tools like Varonis, Acopia, Northern Storage Suite, NTP QFS, TekTools, to name a few, and these have all helped us in the past in deploying a complete solution. I have said on several occasions, and it’s something I really believe in so I’ll say it again; a complete solution is a combination of many different technologies that complement each other.

I’d like to revisit this topic again in a few months when I have progressed my project further, but I’d like to hear from the field to see what other people are doing to gain complete data protection.

New YouTube video showing some of the new features and functionality of NetApp SMVI 2.0. Not sure on a release date just yet, but looks promising!

I’m going to try produce more of these for various guides I do, they are much easier to understand quickly when you’re in a hurry.

The SnapDrive one here is a little dated, so please don’t hold that against the content.

What’s NetApp’s next play? NetApp were very excited a month ago about this potential aqcuisition, so it must fall as quite a disappointment. I heard someone (not from NetApp) voicing the possibility of a Quantum purchase. That would be interesting and very comical as EMC have a lot of that technology in their products! But other than annoying EMC, what benefits would it bring them? Quantum are in a lot of trouble at the moment, so it’d probably be a cheap purchase all the same.

I guess this can only be good news for the consumer though. NetApp will be driven to improve and excel with their de-dupe technology, and maybe give VTL a much-needed make-over.

Related articles by Zemanta

• NetApp Bows Out, Clearing Way for EMC-Data Domain Nuptials (xconomy.com)
• EMC Snagged Data Domain, So What’s Next for NetApp? (gigaom.com)
• EMC Wins Bidding War for Data Domain (nytimes.com)

Management Group

Chargeback

Generate Pre-Built Report

Volume Growth

User usage

Build a Custom Report

Scheduled Reports

Management Group

Creating custom reports from within Ops Mgr is relatively simple. The first step is to create some Management Groups so that we can run reports on certain areas of storage rather than across the entire system.

Next to Groups, click “Edit Groups”

Now give the new group a name. If some groups already exist, you can place the new group inside another if needed. Here we are going to add a new group at the global level. Then click “Add”.

The new group appears at the bottom, but you’ll notice the “Group Membership” reads “Empty”. Click on “Empty” so we can add some filesystem members to this group.

From the drop down on the next page, choose the volumes (or other areas if you wish) that you want to add to this reporting group (use shift or ctrl to select multiples) and use the “>>” button to add them. The page will refresh each time you click this, so it’s easier to select and add multiples. Here we have added all the VMware volumes.

There is no commit button or save button. When you click “>>” these are then added to the group. Over the left hand side we can see this new group, and any related warnings are passed down to it.

Chargeback

When you have management groups setup, you can then setup charging mechanisms per group. This is incredibly useful to help work out the TCO of a NetApp system and also obviously how to charge departments back for their usage (or even just show them how much their usage is costing).

How to calculate your cost per GB should be is outside of the scope of this doc, but should take into account several aspects of the filer management, user admin costs and also the basic costs of storage. To get a full costing all aspects need to be reviewed and adjusted for (power, cooling, space, admin costs, management, and so on). For this example we are simply using 5 per GB (although 50 may be closer to reality on a large system). 5 can be $, £, or whatever you want. Because the £ symbol is not a standard ASCII symbol, we have to enter the HTML character code for it. This is “£”. The currency can be set in “Setup”, “Options”, “Chargeback”. You can also set the defaults here.

Got back into “Edit Groups”

And choose the group we have just setup (here we setup a new group for the User Home Directories).

At the bottom of the page we have an “Annual Charge Rate (per GB)” and you’ll see the default we’ve now set. You can alter this for different areas, so VMware may have a different cost to users home directories. Or FC disk may have a different cost to SATA disk.

Chargeback works on averages, so if this is a fresh system or you have just initialised the quota’s, then this may not give any useful information just yet.

Generate Pre-Built Report

Volume Growth

Now we can create some reports based on this. Click on “Reports” and “All” and we can generate a pre-built report based on our new management group.

We want to create a growth report here, so on the left hand side, under “Logical Objects” choose “Volumes”.

Then choose “Volume Growth”

At the bottom under “Using Resource”, click “Browse”.

Then under “Resources” and “Groups” drill down to our newly created group. Just select the top level group and not the individual members. OK this.

The selection a the bottom changes and click on “Show” and we’ll get our volume growth for this management group.

The below example had only recently been setup, the growth rates have not had chance to be registered.

User usage

For this to work successfully, you need to have some quota’s setup on the users home directories. These don’t have to be hard quota’s, in this example we will be setting up some soft quota’s on the filer, and then reporting against this.

From FilerView, goto “Volumes”, “Quotas”, “Add”.

Here we have a single home directory volume and we are going to add a default User quota based on this.

In this particular volume we have a qtree setup for “normal” users. In this example this is actually just one qtree for all users, but this can be setup to report on multiple qtrees if needed.

For this example here we don’t actually want to use quota’s, we simply want to report against our users. So we are going to use a soft quota of 5 GB. I have also put a soft quota on 50,000 (50k) files. All other entries are left blank to prevent any hard limits or other limits being enforced.

Remember to enable this quota we need to go back to the manage page, check it, and click “on” at the bottom. If it has already been enabled, click “resize” to reload the quota details.

The filer will now scan the volume, if it is large it may take some time…

Once this has complete, verify that it is working as expected by looking at “Quotas” and “Report”. We can see the soft limits working in place for our example here.

I also have setup a “Tree” quota, again with soft limits, on a departmental share with separate Qtrees for each department. We can see the results of that quota below.

Back in Operations Manager. By default the monitoring period for Qtree’s and Quota’s is 8 hours and 1 day respectively. If we are demo’ing this, or setting this up for a customer, we may want to reduce this to allow us to show the immediate effects.

Goto “Setup”, “Discovery”.

Then goto “Monitoring”

And update the Qtree Monitoring and User Quota Monitoring intervals. Here I have changed them to 5 minutes and had a quick coffee break.

We will need a new management group this, so I have created a new group called “User Areas” and I added in the Qtree “/home/normal” into the list of members.

We can check that this has successfully picked up our new quotas and is recognising the users by looking at the “Group Status” and then “Quotas” tab.

We now see a list of all the users and the status of their level. Users with green status will be under quota, those with yellow will be over quota.

Now we can finally report on this usage! Under “Reports”, “All”, then under “Monitoring” choose “User Quotas”.

Choose “User Quotas, All” and make sure you are “Using Resource” for the management group we just setup.

This report is almost identical to the one shown within FilerView, but it is a little easier to understand and is sortable.

Users that no longer exist on the domain will appear with their SID rather than their username.

The limitation here is that Quota’s are entirely driven by ownership. So if a user does not own their home directory, then the above process will not work, you will find that “Administrator” owns a large proportion of user files. This should be addressed as it is best practice to make sure all users own their own files anyway.

Build a Custom Report

If we want to build a custom report, maybe comparing 2 data fields that don’t normally exist on the same report, we can do so. Under “Reports” click “Custom”.

You’ll be taken through to the “Create a Report” page by default. There is a veritable banquet of options for custom reports, so have a careful think before simply diving in to create or show this feature off. It may be best to base what you require on an existing report. Most things are available in the pre-built reports, so it may be that you just want to customise this slightly.

For this example, I want a single report to display the username, disk space used, files used, chargeback, daily growth rate % and days to full.

Whatever report you create must have at least one field taken from the “Base Catalog”, so choose the “Base Catalog” that best suits what you are trying to report on. For this example it is obviously going to be “UserQuota”.

The display tab is quite important as this shows where in Operations Manager this report will be visible from a drop down menu. When you are different pages, Operations Manager gives you different lists that you can choose from. Again, on this occasion it makes sense to include this report in the “Quotas” tab.

Next we need to start defining what information we want to include in this report. So from what I defined at the start, I will start filling out my report. Remember you need at least 1 field from the top level.

Daily Growth Rate %
Days to Full
Disk Space Used
Files Used
Username (note I have to drill down a level to get this info)
Chargeback

Then I need to order this in the way I defined for my report.

And finally click “Create” and we see our new Custom report at the bottom.

To see this report in action, go back “Home”, then click on “User Home Directories” (my custom group), “Quotas” and chose this from the drop down “Report” at the top right.

As mentioned earlier, there are some blanks in this as the report hasn’t been collecting data for long, so there is no data for the growth rate or the chargeback amounts.

If you want to tweak this report, you can go back into “Reports”, “Custom” and select “Edit” from the list at the bottom of the page.

Scheduled Reports

Once you know which reports are useful, or perhaps pulled certain aspects out of different reports to create your own custom one, then you may want to schedule these reports and get them emailed to you. Goto “Reports” and “Schedule”

First we want to create a schedule, so click on the “Schedule” tab and click “Add New Schedule”

Create a schedule based on what your requirements are. Here I want a report generated every Sunday at 8pm.

Now back to “Report Schedules” and we can “Add New Report Schedule”.

From here I can now create my Scheduled Report and the email recipients. I am going to get my new custom report (User Custom Usage) to run against my new management group (User Home Directories) to get generated per my new schedule (Weekly Sunday Evening) and emailed to myself. I’m going to keep the standard HTML formatting and all the other standard settings.

Make sure that a valid mail server has been configured before generating any reports. Goto “Setup”, “Options”, “Events and Alerts”. Here I have also updated the purge interval as I don’t want alerts older than 1 week.

To test this schedule, I want to run it now. Check the checkbox of my new schedule and click “Run Selected”.

The report will be attached in a zip file.

I’ve always liked the way that PHP have their function pages giving users the ability to comment directly onto them. This allows people to leave feedback on functions and tools, and also follow up with some extra uses or syntax for commands that aren’t necessarily clearly published. Hopefully this can feed back into NetApp to improve their documentation.

I’d definitely like to encourage people to comment on the man pages with anything that may be useful, and hopefully build this into a useful little reference section. Many thanks again for the NetApp folk for helping me with this.

Table of Contents

NAME

SYNOPSIS

DESCRIPTION

The aggr command family is new in Data ONTAP 7.0. The vol command family provided control over the traditional vol_umes that fused a single user-visible file system and a single RAID-level storage container (aggregate) into an indivisible unit, and still does. To allow for more flexible use of storage, aggregates now also support the ability to contain multiple, independent user-level file systems named flexible volumes.

Data ONTAP 7.0 fully supports both traditional and flexible volumes. The aggr command family is the preferred method for managing a filer’s aggregates, including those that are embedded in traditional volumes.

Note that most of the aggr commands apply equally to both the type of aggregate that contains flexible volumes and the type that is tightly bound to form a traditional volume. Thus, the term aggregate is often used here to refer to both storage classes. In those cases, it provides a shorthand for the longer and more unwieldy phrase "aggregates and traditional volumes”.

Aggregates may either be mirrored or unmirrored. A plex is a physical copy of the WAFL storage within the aggregate. A mirrored aggregate consists of two plexes; unmirrored aggregates contain a single plex. In order to create a mirrored aggregate, you must have a filer configuration that supports RAID-level mirroring. When mirroring is enabled on the filer, the spare disks are divided into two disk pools. When an aggregate is created, all of the disks in a single plex must come from the same disk pool, and the two plexes of a mirrored aggregate must consist of disks from separate pools, as this maximizes fault isolation. This policy can be overridden with the -f option to aggr create, aggr add and aggr mirror, but it is not recommended.

An aggregate name can contain letters, numbers, and the underscore character(_), but the first character must be a letter or underscore. A combined total of up to 200 aggregates (including those embedded in traditional volumes) can be created on each filer.

A plex may be online or offline. If it is offline, it is not available for read or write access. Plexes can be in combinations of the following states:

normal All RAID groups in the plex are functional.

failed At least one of the RAID groups in the plex has failed.

empty The plex is part of an aggregate that is being created, and one or more of the disks targeted to the aggregate need to be zeroed before being added to the plex.

active The plex is available for use.

inactive
The plex is not available for use.

resyncing
The plex’s contents are currently out of date and are in the process of being resynchronized with the contents of the other plex of the aggregate (applies to mirrored aggregates only).

adding disks
Disks are being added to the plex’s RAID group(s).

out-of-date
This state only occurs in mirrored aggregates where one of the plexes has failed. The non-failed plex will be in this state if it needed to be resynchronized at the time the other plex failed.

A plex is named using the name of the aggregate, a slash character delimiter, and the name of the plex. The system automatically selects plex names at creation time. For example, the first plex created in aggregate aggr0 would be aggr0/plex0.

An aggregate may be online, restricted, or offline. When an aggregate is offline, no read or write access is allowed. When an aggregate is restricted, certain operations are allowed (such as aggregate copy, parity recomputation or RAID reconstruction) but data access is not allowed. Aggregates that are not a part of a traditional volume can only be restricted or offlined if they do not contain any flexible volumes.

Aggregates can be in combinations of the following states:

aggr The aggregate is a modern-day aggregate; it is capable of containing zero or more flexible volumes.

copying
The aggregate is currently the target aggregate of an active aggr copy operation.

degraded
The aggregate contains at least one degraded RAID group that is not being reconstructed.

foreign
The disks that the aggregate contains were moved to the current filer from another filer.

growing
Disks are in the process of being added to the aggregate.

initializing
The aggregate is in the process of being initialized.

invalid
The aggregate contains no volumes and none can be added. Typically this happens only after an aborted aggregate copy operation.

ironing
A WAFL consistency check is being performed on this aggregate.

mirror degraded
The aggregate is a mirrored aggregate, and one of its plexes is offline or resyncing.

mirrored
The aggregate is mirrored and all of its RAID groups are functional.

needs check
A WAFL consistency check needs to be performed on the aggregate.

partial
At least one disk was found for the aggregate, but two or more disks are missing.

raid0 The aggregate consists of RAID-0 (no parity) RAID groups (V-Series and NetCache only).

raid4 The aggregate consists of RAID-4 RAID groups.

raid_dp
The aggregate consists of RAID-DP (Double Parity) RAID groups.

reconstruct
At least one RAID group in the aggregate is being reconstructed.

redirect
Aggregate reallocation or file reallocation with the -p option has been started on the aggregate. Read performance to volumes in the aggregate may be degraded.

resyncing
One of the plexes of a mirrored aggregate is being resynchronized.

snapmirrored
The aggregate is a snapmirrored replica of another aggregate. This state can only arise if the aggregate is part of a traditional volume.

trad The aggregate is fused with a single volume. This is also referred to as a traditional volume and is exactly equivalent to the volumes that existed before Data OnTAP 7.0. Flexible volumes can not be created inside of this aggregate.

verifying
A RAID mirror verification operation is currently being run on the aggregate.

wafl inconsistent
The aggregate has been marked corrupted. Please contact Customer Support if you see an aggregate in this state.

USAGE

  add             mirror          restrict        undestroy   copy            offline         scrub           verify   create          online          show_space   destroy         options         split   media_scrub     rename          status 

|

-d disk1 [ disk2 ... ] [ -d diskn [ diskn+1 ... ] ] }

If the -g option is not used, the disks are added to the most recently created RAID group util it is full, and then one or more new RAID groups are created and the remaining disks are added to new groups. Any other existing RAID groups that are not full remain partially filled.

The -g option allows specification of a RAID group (for example, rg0) to which the indicated disks should be added, or a method by which the disks are added to new or existing RAID groups.

If the -g option is used to specify a RAID group, that RAID group must already exist. The disks are added to that RAID group util it is full. Any remaining disks are ignored.

If the -g option is followed by new, Data ONTAP creates one or more new RAID groups and adds the disks to them, even if the disks would fit into an existing RAID group. Any existing RAID groups that are not full remain partially filled. The name of the new RAID groups are selected automatically. It is not possible to specify the names for the new RAID groups.

If the -g option is followed by all, Data ONTAP adds the specified disks to existing RAID groups first. After all existing RAID groups are full, it creates one or more new RAID groups and adds the specified disks to the new groups.

The -n option can be used to display the command that the system will execute, without actually making any changes. This is useful for displaying the automatically selected disks, for example.

By default, the filer fills up one RAID group with disks before starting another RAID group. Suppose an aggregate currently has one RAID group of 12 disks and its RAID group size is 14. If you add 5 disks to this aggregate, it will have one RAID group with 14 disks and another RAID group with 3 disks. The filer does not evenly distribute disks among RAID groups.

You cannot add disks to a mirrored aggregate if one of the plexes is offline.

The disks in a plex are not permitted to span disk pools. This behavior can be overridden with the -f flag when used together with the -d argument to list disks to add. The -f flag, in combination with -d, can also be used to force adding disks that have a rotational speed that does not match that of the majority of existing disks in the aggregate.

aggr copy abort [ -h] operation_number | all

Terminates aggregate copy operations. The opera_tion_number parameter specifies which operation to terminate. If you specify all, all aggregate active copy operations are terminated.

aggr copy start
[ -S | -s snapshot ] [ -C ]
source destination

Copies all data, including snapshots and flexible volumes, from one aggregate to another. If the -S flag is used, the command copies all snapshots in the source aggregate to the destination aggregate. To specify a particular snapshot to copy, use the -s flag followed by the name of the snapshot. If you use neither the -S nor -s flag in the command, the filer creates a snapshot at the time when the aggr copy start command is executed and copies only that snapshot to the destination aggregate.

The -C flag is required if the source aggregate has had free-space defragmentation performed on it, or if the destination aggregate will be free-space defragmented. Free-space defragmentation can be performed on an aggregate using the reallocate command.

Aggregate copies can only be performed between aggregates that host flexible volumes. Aggregates that are embedded in traditional volumes cannot participate.

The source and destination aggregates can be on the same filer or different filers. If the source or destination aggregate is on a filer other than the one on which you enter the aggr copy start command, specify the aggregate name in the filer_name:aggre_gate_name format.

The filers involved in an aggregate copy must meet the following requirements for the aggr copy start command to be completed successfully:

The source aggregate must be online and the destination aggregate must be restricted.

If the copy is between two filers, each filer must be defined as a trusted host of the other filer. That is, the filer’s name must be in the /etc/hosts.equiv file of the other filer.

If the copy is on the same filer, localhost must be included in the filer’s /etc/hosts.equiv file. Also, the loopback address must be in the filer’s /etc/hosts file. Otherwise, the filer cannot send packets to itself through the loopback address when trying to copy data.

The usable disk space of the destination aggregate must be greater than or equal to the usable disk space of the source aggregate. Use the df -A pathname command to see the amount of usable disk space of a particular aggregate.

Each aggr copy start command generates two aggregate copy operations: one for reading data from the source aggregate and one for writing data to the destination aggregate. Each filer supports up to four simultaneous aggregate copy operations.

aggr copy status [ operation_number ]

Displays the progress of one or all aggr copy operations. The operations are numbered from 0 through 3.

Restart checkpoint information for all transfers is also displayed.

aggr copy throttle [ operation_number ] value

Controls the performance of the aggr copy operation. The value ranges from 10 (full speed) to 1 (one-tenth of full speed). The default value is maintained in the filer’s aggr.copy.throttle option and is set 10 (full speed) at the factory. You can apply the performance value to an operation specified by the operation_number parameter. If you do not specify an operation number in the aggr copy throttle command, the command applies to all aggr copy operations.

Use this command to limit the speed of the aggr copy operation if you suspect that the aggr copy operation is causing performance problems on your filer. In particular, the throttle is designed to help limit the CPU usage of the aggr copy operation. It cannot be used to fine-tune network bandwidth consumption patterns.

The aggr copy throttle command only enables you to set the speed of an aggr copy operation that is in progress. To set the default aggr copy speed to be used by future copy operations, use the options command to set the aggr.copy.throttle option.

aggr create aggrname
[ -f ]
[ -m ]
[ -n ]
[ -t raidtype ]
[ -r raidsize ]
[ -T disk-type ]
[ -R rpm ]
[ -L [compliance | enterprise] ]
[ -v ]
[ -l language-code ]
{ ndisks[@size]

|

-d disk1 [ disk2 ... ] [ -d diskn [ diskn+1 ... ] ] }

An embedded aggregate can be created as part of a traditional volume using the -v option. It cannot contain any flexible volumes.

A regular aggregate, created without the -v option, can contain only flexible volumes. It cannot be incorporated into a traditional volume, and it contains no volumes immediately after creation. New flexible volumes can be created using the vol create command.

The -t raidtype argument specifies the type of RAID group(s) to be used to create the aggregate. The possible RAID group types are raid4 for RAID-4, raid_dp for RAID-DP (Double Parity), and raid0 for simple striping without parity protection. The default raidtype for aggregates and traditional volumes on filers is raid_dp. Setting the raidtype is not permitted on V-Series systems; the default of raid0 is always used.

The -r raidsize argument specifies the maximum number of disks in each RAID group in the aggregate. The maximum and default values of raidsize are platform-dependent, based on performance and reliability considerations. See aggr options raidsize for more details.

The -T disk-type argument specifies the type of disks to use when creating a new aggregate. It is needed only on systems connected to disks of different types. Possible disk types are: ATA, FCAL, LUN, SAS, SATA, and SCSI. Mixing disks of different types in one aggregate is not allowed. -T cannot be used together with -d.

Disk type identifies disk technology and connectivity type. ATA identifies ATA disks with either IDE or serial ATA interface in shelves connected in FCAL (Fibre Channel Arbitrated Loop). FCAL identifies FC disks in shelves connected in FC-AL. LUN identifies virtual disks exported from external storage arrays. The underlying disk technology and RAID type depends on implementation of such external storage arrays. SAS identifies Serial Attached SCSI disks in matching shelves. SATA identifies serial ATA disks in SAS shelves. SCSI stands for Small Computer System Interface, and it is included for backward compatibility with earlier disk technologies.

The -R rpm argument specifies the type of disks to use based on their rotational speed in revolutions per minute (rpm). It is needed only on systems having disks with different rotational speeds. Typical values for rotational speed are 5400, 7200, 10000, and 15000. -R cannot be used together with -d.

ndisks is the number of disks in the aggregate, including the parity disks. The disks in this newly created aggregate come from the pool of spare disks. The smallest disks in this pool join the aggregate first, unless you specify the @size argument. size is the disk size in GB, and disks that are within 10% of the specified size will be selected for use in the aggregate.

The -m option can be used to specify that the new aggregate be mirrored (have two plexes) upon creation. If this option is given, then the indicated disks will be split across the two plexes. By default, the new aggregate will not be mirrored.

The -n option can be used to display the command that the system will execute, without actually making any changes. This is useful for displaying the automatically selected disks, for example.

If you use the -d disk1 [ disk2 ... ] argument, the filer creates the aggregate with the specified spare disks disk1, disk2, and so on. You can specify a space-separated list of disk names. Two separate lists must be specified if the new aggregate is mirrored. In the case that the new aggregate is mirrored, the indicated disks must result in an equal number of disks on each new plex.

The disks in a plex are not permitted to span spare pools. This behavior can be overridden with the -f option. The same option can also be used to force using disks that do not have matching rotational speed. The -f option has effect only when used with the -d option specifying disks to use.

To create a SnapLock aggregate, specify the -L flag with the aggr create command. This flag is only supported if either SnapLock Compliance or SnapLock Enterprise is licensed. The type of the SnapLock aggregate created, either Compliance or Enterprise, is determined by the installed SnapLock license. If both SnapLock Compliance and SnapLock Enterprise are licensed, use -L compliance or -L enterprise to specify the desired aggregate type.

The -l language_code argument may be used only when creating a traditional volume using option -v. The filer creates the traditional volume with the language specified by the language code. The default is the language used by the filer’s root volume. See the vol man page for a list of language codes.

aggr destroy { aggrname | plexname } [ -f ]

Destroys the aggregate named aggrname, or the plex named plexname. Note that if the specified aggregate is tied to a traditional volume, then the traditional volume itself is destroyed as well.

If an aggregate is specified, all plexes in the aggregate are destroyed. The named aggregate must also not contain any flexible volumes, regardless of their mount state (online, restricted, or offline). If a plex is specified, the plex is destroyed, leaving an unmirrored aggregate or traditional volume containing the remaining plex. Before destroying the aggregate, traditional volume or plex, the user is prompted to confirm the operation. The -f flag can be used to destroy an aggregate, traditional volume or plex without prompting the user.

The disks originally in the destroyed object become spare disks. Only offline aggregates, traditional volumes and plexes can be destroyed.

aggr media_scrub status [ aggrname | plexname | groupname ]
[ -v ]

Prints the media scrubbing status of the named aggregate, plex, or group. If no name is given, then status is printed for all RAID groups currently running a media scrub. The status includes a percent-complete and whether it is suspended.

The -v flag displays the date and time at which the last full media scrub completed, the date and time at which the current instance of media scrubbing started, and the current status of the named aggregate, plex, or group. If no name is given, this more verbose status is printed for all RAID groups with active media scrubs.

aggr mirror aggrname
[ -f ]
[ -n ]
[ -v victim_aggrname ]
[ -d disk1 [ disk2 ... ] ]

Turns an unmirrored aggregate into a mirrored aggregate by adding a plex to it. The plex is either newly-formed from disks chosen from a spare pool, or, if the -v option is specified, is taken from another existing unmirrored aggregate. Aggregate aggrname must currently be unmirrored. Use aggr create to make a new, mirrored aggregate from scratch.

Disks may be specified explicitly using -d in the same way as with the aggr create and aggr add commands. The number of disks indicated must match the number present on the existing aggregate. The disks specified are not permitted to span disk pools. This behavior can be overridden with the -f option. The -f option, in combination with -d, can also be used to force using disks that have a rotational speed that does not match that of the majority of existing disks in the aggregate.

If disks are not specified explicitly, then disks are automatically selected to match those in the aggregate’s existing plex.

The -v option can be used to join victim_aggrname back into aggrname to form a mirrored aggregate. The result is a mirrored aggregate named aggrname which is otherwise identical to aggrname before the operation. Victim_aggrname is effectively destroyed. Victim_aggrname must have been previously mirrored with aggrname, then separated via the aggr split command. Victim_aggrname must be offline. Combined with the -v option, the -f option can be used to join aggrname and vic_tim_aggrname without prompting the user.

The -n option can be used to display the command that the system will execute without actually making any changes. This is useful for displaying the automatically selected disks, for example.

aggr offline { aggrname | plexname }
[ -t cifsdelaytime ]

Takes the aggregate named aggrname (or the plex named plexname) offline. The command takes effect before returning. If the aggregate is already in restricted state, then it is already unavailable for data access, and much of the following description does not apply.

If the aggregate contains any flexible volumes, then the operation is aborted unless the filer is in maintenance mode.

Except in maintenance mode, the aggregate containing the current root volume may not be taken offline. An aggregate containing a volume that has been marked to become root (using vol options vol_name root) also cannot be taken offline.

If the aggregate is embedded in a traditional volume that has CIFS shares, users should be warned before taking the aggregate (and hence the entire traditional volume) offline. Use the -t switch for this. The cifsdelaytime argument specifies the number of minutes to delay before taking the embedded aggregate offline, during which time CIFS users of the traditional volume are warned of the pending loss of service. A time of 0 means take the aggregate offline immediately with no warnings given. CIFS users can lose data if they are not given a chance to terminate applications gracefully.

If a plexname is specified, the plex must be part of a mirrored aggregate and both plexes must be online. Prior to offlining a plex, the system will flush all internally-buffered data associated with the plex and create a snapshot that is written out to both plexes. The snapshot allows for efficient resynchronization when the plex is subsequently brought back online.

A number of operations being performed on the aggregate’s traditional volume can prevent aggr offline from succeeding, for various lengths of time. If such operations are found, there will be a one-second wait for such operations to finish. If they do not, the command is aborted.

A check is also made for files in the aggregate’s associated traditional volume opened by internal ONTAP processes. The command is aborted if any are found.

aggr online { aggrname | plexname }
[ -f ]

Brings the aggregate named aggrname (or the plex named plexname) online. This command takes effect immediately. If the specified aggregate is embedded in a traditional volume, the volume is also also brought online.

If an aggrname is specified, it must be currently offline, restricted, or foreign. If the aggregate is foreign, it will be made native before being brought online. A “foreign” aggregate is an aggregate that consists of disks moved from another filer and that has never been brought online on the current filer. Aggregates that are not foreign are considered “native.”

If the aggregate is inconsistent, but has not lost data, the user will be cautioned and prompted before bringing the aggregate online. The -f flag can be used to override this behavior. It is advisable to run WAFL_check (or do a snapmirror initialize in case of an aggregate embedded in a traditional volume) prior to bringing an inconsistent aggregate online. Bringing an inconsistent aggregate online increases the risk of further file system corruption. If the aggregate is inconsistent and has experienced possible loss of data, it cannot be brought online unless WAFL_check (or snapmirror initialize in the embedded case) has been run on the aggregate.

If a plexname is specified, the plex must be part of an online mirrored aggregate. The system will initiate resynchronization of the plex as part of online processing.

aggr options aggrname [ optname optval ]

Displays the options that have been set for aggregate aggrname, or sets the option named optname of the aggregate named aggrname to the value optval. The command remains effective after the filer is rebooted, so there is no need to add aggr options commands to the /etc/rc file. Some options have values that are numbers. Some options have values that may be on (which can also be expressed as yes, true, or 1 ) or off (which can also be expressed as no, false, or 0). A mixture of uppercase and lowercase characters can be used when typing the value of an option. The aggr status command displays the options that are set per aggregate.

The following describes the options and their possible values:

fs_size_fixed on | off

This option only applies to aggregates that are embedded in traditional volumes. It causes the file system to remain the same size and not grow or shrink when a SnapMirrored volume relationship is broken, or an aggr add is performed on it. This option is automatically set to be on when a traditional volume becomes a SnapMirrored volume. It will remain on after the snapmirror break command is issued for the traditional volume. This allows a traditional volume to be SnapMirrored back to the source without needing to add disks to the source traditional volume. If the traditional volume size is larger than the file system size, turning off this option will force the file system to grow to the size of the traditional volume. The default setting is off.

ignore_inconsistent on | off

This command can only be used in maintenance mode. If this option is set, it allows the aggregate containing the root volume to be brought online on booting, even though it is inconsistent. The user is cautioned that bringing it online prior to running WAFL_check or wafliron may result in further file system inconsistency.

nosnap on | off

If this option is on, it disables automatic snapshots on the aggregate. The default setting is off.

raidsize number

The value of this option is the maximum size of a RAID group that can be created in the aggregate. Changing the value of this option will not cause existing RAID groups to grow or shrink; it will only affect whether more disks will be added to the last existing RAID group and how large new RAID groups will be.

Legal values for this option depend on raidtype. For example, raid_dp allows larger RAID groups than raid4. Limits and default values are also different for different types of filer appliances and different types of disks. Following tables define limits and default values for raidsize.

  ——————————————    raid4 raidsize       min   default   max   ——————————————    R100                  2        8       8    R150                  2        6       6    FAS250                2        7      14    other (FCAL disks)    2        8      14    other (ATA disks)     2        7       7   ——————————————     ——————————————    raid_dp raidsize     min   default   max   ——————————————    R100                  3       12      12    R150                  3       12      16    other (FCAL disks)    3       16      28    other (ATA disks)     3       14      16   —————————————— 

raidtype raid4 | raid_dp | raid0

Sets the type of RAID used to protect against disk failures. Use of raid4 provides one parity disk per RAID group, while raid_dp provides two. Changing this option immediately changes the RAID type of all RAID groups within the aggregate. When upgrading RAID groups from raid4 to raid_dp, each RAID group begins a reconstruction onto a spare disk allocated for the second `dparity’ parity disk.

Changing this option also changes raidsize to a more suitable value for new raidtype. When upgrading from raid4 to raid_dp, raidsize will be increased to the default value for raid_dp. When downgrading from raid_dp to raid4, raidsize will be decreased to the size of the largest existing RAID group if it is between the default value and the limit for raid4. If the largest RAID group is above the limit for raid4, the new raidsize will be that limit. If the largest RAID group is below the default value for raid4, the new raidsize will be that default value. If raidsize is already below the default value for raid4, it will be reduced by 1.

resyncsnaptime number

This option is used to set the mirror resynchronization snapshot frequency (in minutes). The default value is 60 minutes.

root

If this option is set on a traditional volume, then the effect is identical as that defined in vol man page. Otherwise, if this option is set on an aggregate capable of containing flexible volumes, then that aggregate is marked as being the one that will also contains the root flexible volume on the next reboot. This option can be used on only one aggregate or traditional volume at any given time. The existing root aggregate or traditional volume will become a non-root entity after the reboot.

Until the system is rebooted, the original aggregate and/or traditional volume will continue to show root as one of its options, and the new root aggregate or traditional volume will show diskroot as an option. In general, the aggregate that has the diskroot option is the one that will contain the root flexible volume following the next reboot.

The only way to remove the root status of an aggregate or traditional volume is to set the root option on another aggregate or traditional volume.

snaplock_compliance

This read only option indicates that the aggregate is a SnapLock Compliance aggregate. Aggregates can only be designated SnapLock Compliance aggregates at creation time.

snaplock_enterprise

This read only option indicates that the aggregate is a SnapLock Enterprise aggregate. Aggregates can only be designated SnapLock Enterprise aggregates at creation time.

snapmirrored off

If SnapMirror is enabled for a traditional volume (SnapMirror is not supported for aggregates that contain flexible volumes), the filer automatically sets this option to on. Set this option to off if SnapMirror is no longer to be used to update the traditional volume mirror. After setting this option to off, the mirror becomes a regular writable traditional volume. This option can only be set to off; only the filer can change the value of this option from off to on.

snapshot_autodelete on | off

This option is used to set whether snapshot are automatically deleted in the aggr. If set to on then snapshots may be deleted in the aggr to recover storage as necessary. If set to off then snapshots in the aggr are not automatically deleted to recover storage. Note that snapshots may still be deleted for other reasons, such as maintaining the snapshot schedule for the aggr, or deleting snapshots that are associated with specific operations that no longer need the snapshot. To allow snapshots to be deleted in a timely manner the number of aggr snapshots is limited when snapshot_autodelete is enabled. Because of this, if there are too many snapshots in an aggr then some snapshots must be deleted before the snapshot_autodelete option can be enabled.

aggr rename aggrname newname

Renames the aggregate named aggrname to newname. If this aggregate is embedded in a traditional volume, then that volume’s name is also changed.

aggr restrict aggrname
[ -t cifsdelaytime ]

Put the aggregate named aggrname in restricted state, starting from either online or offline state. The command takes effect before returning.

If the aggregate contains any flexible volumes, the operation is aborted unless the filer is in maintenance mode.

If the aggregate is embedded in a traditional volume that has CIFS shares, users should be warned before restricting the aggregate (and hence the entire traditional volume). Use the -t switch for this. The cifsdelaytime argument specifies the number of minutes to delay before taking the embedded aggregate offline, during which time CIFS users of the traditional volume are warned of the pending loss of service. A time of 0 means take the aggregate offline immediately with no warnings given. CIFS users can lose data if they are not given a chance to terminate applications gracefully.

aggr scrub resume [ aggrname | plexname | groupname ]

Resumes parity scrubbing on the named aggregate, plex, or group. If no name is given, resume all RAID groups currently undergoing a parity scrubbing that has been suspended.

aggr scrub start [ aggrname | plexname | groupname ]

Starts parity scrubbing on the named online aggregate. Parity scrubbing compares the data disks to the parity disk(s) in their RAID group, correcting the parity disk’s contents as necessary. If no name is given, parity scrubbing is started on all online aggregates. If an aggregate name is given, scrubbing is started on all RAID groups contained in the aggregate. If a plex name is given, scrubbing is started on all RAID groups contained in the plex.

aggr scrub status [ aggrname | plexname | groupname ] [ -v ]

Prints the status of parity scrubbing on the named aggregate, plex, or group; all RAID groups currently undergoing parity scrubbing if no name is given. The status includes a percent-complete, and the scrub’s suspended status.

The -v flag displays the date and time at which the last full scrub completed along with the current status on the named aggregate, plex, or group; all RAID groups if no name is given.

aggr scrub stop [ aggrname | plexname | groupname ]

Stops parity scrubbing on the named aggregate, plex, or group; if no name is given, on all RAID groups currently undergoing a parity scrubbing.

aggr scrub suspend [ aggrname | plexname | groupname ]

Suspends parity scrubbing on the named aggregate, plex, or group; if no name is given, on all RAID groups currently undergoing parity scrubbing.

aggr show_space [ -h | -k | -m | -g | -t | -b ] < aggrname >

Displays the space usage in an aggregate. Unlike df, this command shows the space usage for each flexible volume within an aggregate If aggrname is specified, aggr show_space only runs on the corresponding aggregate, otherwise it reports space usage on all the aggregates.

All sizes are reported in 1024-byte blocks, unless otherwise requested by one of the -h, -k, -m, -g, or -t options. The -k, -m, -g, and -t options scale each size-related field of the output to be expressed in kilobytes, megabytes, gigabytes, or terabytes respectively.

The following terminology is used by the command in reporting space.

      Total space      This is the amount of total disk space                        that the aggregate has.        WAFL reserve     WAFL reserves a percentage of the total                        total disk space for aggregate level metadata.                        The space used for maintaining the volumes in                        the aggregate comes out of the WAFL reserve.        Snap reserve     Snap reserve is the amount of space                        reserved for aggregate snapshots.        Usable space     This is the total amount of space that                        is available to the aggregate for provisioning.                        This is computed as                        Usable space = Total space –                                       WAFL reserve –                                       Snap reserve                        df displays this as the ‘total’ space.        BSR NVLOG        This is valid for Synchronous SnapMirror                        destinations only. This is the amount of space                        used in the aggregate on the destination filer to                        store data sent from the source filer(s) before                        sending it to disk.        Allocated        This is the sum of the space reserved                        for the volume and the space used by non                        reserved data. For volume guaranteed                        volumes,  this is at least the size of the                        volume since no data is unreserved. For                        volumes with space guarantee of none,  this                        value is the same as the ‘Used’ space                        (explained below) since no unused space is                        reserved. The Allocated space value                        shows the amount of space that the volume                        is taking from the aggregate. This value can                        be greater than the size of the volume because                        it also includes the metadata required to                        maintain the volume.        Used             This is the amount of space that is taking                        up disk blocks. This value is not the same                        as the ‘used’ space displayed by the df                        command. The Used space in this case                        includes the metadata required to maintain                        the flexible volume.        Avail            Total amount of free space in the aggregate.                        This is the same as the avail space reported                        by df.  

Removes plexname from a mirrored aggregate and creates a new unmirrored aggregate named aggrname that contains the plex. The original mirrored aggregate becomes unmirrored. The plex to be split from the original aggregate must be functional (not partial), but it could be inactive, resyncing, or outof-date. Aggr split can therefore be used to gain access to a plex that is not up to date with respect to its partner plex, if its partner plex is currently failed.

If the aggregate in which plexname resides is embedded in a traditional volume, aggr split behaves identically to vol split. The new aggregate is embedded in a new traditional volume of the same name.

If the aggregate in which plexname resides contains exactly one flexible volume, aggr split will by default rename the flexible volume image in the split-off plex to be the same as the new aggregate.

If the aggregate in which plexname resides contains more than one flexible volume, it is necessary to specify how to name the volumes in the new aggregate resulting from the split. The -r option can be used repeatedly to give each flexible volume in the resulting aggregate a new name. In addition, the -s option can be used to specify a suffix that is added to the end of all flexible volume names not covered by a -r.

If the original aggregate is restricted at the time of the split, the resulting aggregate will also be restricted. If the restricted aggregate is hosting flexible volumes, they are not renamed at the time of the split. Flexible volumes will be renamed later, when the name conflict is detected while bringing an aggregate online. Flexible volumes in the aggregate that is brought online first keep their names. That aggregate can be either the original aggregate, or the aggregate resulting from the split. When the other aggregate is brought online later, flexible volumes in that aggregate will be renamed.

If the plex of an aggregate embedded within a traditional volume is offline at the time of the split, the resulting aggregate will be offline. When splitting a plex from an aggregate that hosts flexible volumes, if that plex is offline, but the aggregate is online, the resulting aggregate will come online, and its flexible volumes will be renamed. It is not allowed to split a plex from an offline aggregate.

A split mirror can be joined back together via the -v option to aggr mirror.

aggr status [ aggrname ]
[ -r | -v | -d | -c | -b | -s | -f | -i ]

Displays the status of one or all aggregates on the filer. If aggrname is used, the status of the specified aggregate is printed; otherwise the status of all aggregates in the filer are printed. By default, it prints a one-line synopsis of the aggregate which includes the aggregate name, whether it contains a single traditional volume or some number of flexible volumes, if it is online or offline, other states (for example, partial, degraded, wafl inconsistent, and so on) and peraggregate options. Per-aggregate options are displayed only if the options have been changed from the system default values by using the aggr options command, or by the vol options command if the aggregate is embedded in a traditional volume. If the wafl inconsistent state is displayed, please contact Customer Support.

The -v flag shows the on/off state of all peraggregate options and displays information about each volume, plex and RAID group contained in the aggregate.

The -r flag displays a list of the RAID information for that aggregate. If no aggrname is specified, it prints RAID information about all aggregates, information about file system disks, spare disks, and failed disks. For more information about failed disks, see the -f switch description below.

The -d flag displays information about the disks in the specified aggregate. The types of disk information are the same as those from the sysconfig -d command.

The -c flag displays the upgrade status of the Block Checksums data integrity protection feature.

The -b is used to get the size of source and destination aggregates for use with aggr copy. The output contains the storage in the aggregate and the possibly smaller size of the aggregate. The aggregate copy command uses these numbers to determine if the source and destination aggregate sizes are compatible. The size of the source aggregate must be equal or smaller than the size of the destination aggregate.

The -s flag displays a listing of the spare disks on the filer.

The -f flag displays a list of the failed disks on the filer. The command output includes the disk failure reason which can be any of following:

The -i flag displays a list of the flexible volumes contained in an aggregate.

      unknown           Failure reason unknown.       failed            Data ONTAP failed disk due to a                         fatal disk error.       admin failed      User issued a ‘disk fail’ command                         for this disk.       labeled broken    Disk was failed under Data ONTAP                         6.1.X or an earlier version.       init failed       Disk initialization sequence failed.       admin removed     User issued a ‘disk remove’ command                         for this disk.       not responding    Disk not responding to requests.       pulled            Disk was physically pulled,  or no                         data path exists on which to access                         the disk.       bypassed          Disk was bypassed by ESH. 

Undestroy a partially intact or previously destroyed aggregate or traditional volume. The command prints a list of candidate aggregates and traditional volumes matching the given name, which can be potentially undestroyed.

The -n option prints the list of disks contained by the aggregate or by the traditional volume, which can be potentially undestroyed. This option can be used to display the result of command execution, without actually making any changes.

aggr verify resume [ aggrname ]

Resumes RAID mirror verification on the named aggregate; if no aggregate name is given, on all aggregates currently undergoing a RAID mirror verification that has been suspended.

aggr verify start [ aggrname ] [ -f plexnumber ]

Starts RAID mirror verification on the named online mirrored aggregate. If no name is given, then RAID mirror verification is started on all online mirrored aggregates. Verification compares the data in both plexes of a mirrored aggregate. In the default case, all blocks that differ are logged, but no changes are made. If the -f flag is given, the plex specified is fixed to match the other plex when mismatches are found. A name must be specified with the -f plexnumber option.

aggr verify stop [ aggrname ]

Stops RAID mirror verification on the named aggregate; if no aggregate name is given, on all aggregates currently undergoing a RAID mirror verification.

aggr verify status [ aggrname ]

Prints the status of RAID mirror verification on the named aggregate; on all aggregates currently undergoing RAID mirror verification if no aggregate name is given. The status includes a percent-complete, and the verification’s suspended status.

aggr verify suspend [ aggrname ]

Suspends RAID mirror verification on the named aggregate; if no aggregate name is given, on all aggregates currently undergoing RAID mirror verification.

CLUSTER CONSIDERATIONS

However, having unique aggregate names in a cluster makes it easier to migrate aggregates between the filers in the cluster.

EXAMPLES

Creates an aggregate named aggr1 with 20 disks. The RAID groups in this aggregate can contain up to 10 disks, so this new aggregate has two RAID groups. The filer adds the current spare disks to the new aggregate, starting with the smallest disk.

aggr create aggr1 20@9

Creates an aggregate named aggr1 with 20 9-GB disks. Because no RAID group size is specified, the default size (8 disks) is used. The newly-created aggregate contains two RAID groups with 8 disks and a third group with four disks.

aggr create aggr1 -d 8a.1 8a.2 8a.3

Creates an aggregate named aggr1 with the specified three disks.

aggr create aggr1 10
aggr options aggr1 raidsize 5

The first command creates an aggregate named aggr1 with 10 disks which belong to one RAID group. The second command specifies that if any disks are subsequently added to this aggregate, they will not cause any current RAID group to have more than five disks. Each existing RAID group will continue to have 10 disks and no more disks will be added to that RAID group. When new RAID groups are created, they will have a maximum size of five disks.

aggr show_space -h ag1

Displays the space usage of the aggregate `ag1′ and scales the unit of space according to the size.

  Aggregate ‘ag1′    Total space    WAFL reserve    Snap reserve    Usable space       BSR NVLOG          66GB          6797MB           611MB            59GB            65KB    Space allocated to volumes in the aggregate    Volume            Allocated            Used       Guarantee   vol1                   14GB            11GB          volume   vol2                 8861MB          8871MB            file   vol3                 6161MB          6169MB            none   vol4                   26GB            25GB          volume   vol1_clone           1028MB          1028MB       (offline)    Aggregate         Allocated            Used           Avail   Total space            55GB            51GB          3494MB   Snap reserve          611MB            21MB           590MB   WAFL reserve         6797MB          5480KB          6792MB 

aggr status aggr1 -r

Displays the RAID information about aggregate aggr1. In the following example, we see that aggr1 is a RAID-DP aggregate protected by block checksums. It is online, and all disks are operating normally. The aggregate contains four disks -two data disks, one parity disk, and one doubleparity disk. Two disks are located on adapter 0b, and two on adapter 1b. The disk shelf and bay numbers for each disk are indicated. All four disks are 10, 000 RPM FibreChannel disks attached via disk channel A. The disk "Pool" attribute is displayed only if SyncMirror is licensed, which is not the case here (if SyncMirror were licensed, Pool would be either 0 or 1). The amount of disk space that is used by Data ONTAP (“Used”) and is available on the disk (“Phys”) is displayed in the rightmost columns.

  Aggr aggr1 (online,  raid_dp) (block checksums)     Plex /aggr1/plex0 (online,  normal,  active)       RAID group /aggr1/plex0/rg0 (normal)          RAID Disk Device  HA  SHELF BAY CHAN Pool Type  RPM  Used (MB/blks)    Phys (MB/blks)         ——— ——  ————- —- —- —- —– ————–    ————–         dparity   0b.16   0b    1   0   FC:A   –  FCAL 10000 136000/278528000  137104/280790184         parity    1b.96   1b    6   0   FC:A   –  FCAL 10000 136000/278528000  139072/284820800         data      0b.17   0b    1   1   FC:A   –  FCAL 10000 136000/278528000  139072/284820800         data      1b.97   1b    6   1   FC:A   –  FCAL 10000 136000/278528000  139072/284820800  

SEE ALSO

Table of Contents

• NAME
• SYNOPSIS
• DESCRIPTION
• USAGE
• CLUSTER CONSIDERATIONS
• EXAMPLES
• SEE ALSO

Copyright © 1994-2008 NetApp, Inc. Legal Information