Table of Contents
The automated allocation management process consists of three main steps:
1. Measure the current layout. If the optimization is less than a threshold value, then take no action. This step is optional.
2. Perform reallocation.
3. Measure the layout again. If the optimization is above the threshold value, repeat steps 2. and 3. as necessary.
When performing aggregate reallocation only step 2 currently applies. This is split into two phases:
2a. Perform block reallocation of the aggregate.
2b. Fix up the flexible volume information within the aggregate.
These steps, together with scheduling and other information comprise a reallocation job.
Reallocation processing operates as a background task. Output goes to the system log. Current status may be viewed using the reallocate status subcommand.
A reallocation job can be run at a specific interval, which is the default, or at scheduled times, set using the reallocate schedule subcommand.
The reallocation process balances the data blocks reallocated against the performance gained by performing the reallocation. It only reallocates blocks when a performance improvement is predicted. That is, if a section of a file or LUN is already optimal then no change will be made. In addition, full one-time reallocation of a large file, LUN or a whole volume, can be forced by using the -f option with reallocate start. A full reallocation will reallocate data unless the performance is predicated to be worse after the movement. Full reallocation is equivalent to using wafl scan reallocate.
Enable or disable reallocation jobs globally. When jobs are off no new reallocation jobs may be started or restarted. Any existing jobs that are executing will be requested to stop.
reallocate start [-t threshold] [-i interval] [-n] [-o] [-p] [-u] pathname | /vol/volname
Start reallocation on the LUN or large file specified by pathname. If a volume has many small files that would benefit from periodic optimization then a whole volume may also be specified by using /vol/volname.
The reallocation job normally performs a check for the current layout optimization before performing reallocation. If the current optimization is less than the threshold then no reallocation will be performed. If the -n option is specified this check is suppressed. The threshold to use may be specified by the -t option (see below).
The reallocation job will be run periodically at a system-defined interval. The interval between runs may be changed with the -i (interval) option The interval is specified as a number of minutes, hours or days, NNN[mhd]. Note, depending on the system configuration and write/read workload it may be appropriate to have the job run at a close interval or at a long interval. If the -o (once) option is used then the job will be run once only, and then automatically removed from the system.
The threshold when a LUN, file or volume is considered unoptimized enough that a reallocation should be performed is given as a number from 3 (moderately optimized) to 10 (very unoptimized). For users of the wafl scan measure_layout command these thresholds are comparable with the ratio output. The default threshold is 4.
The -p option requests that reallocation of user data take place on the physical blocks in the aggregate, but the logical block locations within a flexible volume are preserved. This option may only be used with flexible volumes, or files/LUNs within flexible volumes.
Using the -p option may reduce the extra storage requirements in a flexible volume when reallocation is run on a volume with snapshots. It may also reduce the amount of data that needs to be transmitted by SnapMirror on its next update after reallocation is performed on a SnapMirror source volume.
Using the -p option may cause a performance degradation reading older snapshots if the volume has significantly changed after reallocation has been performed. Examples of reading a snapshot include reading files in the .snapshot directory, accessing a LUN backed by a snapshot, or reading a qtree snapmirror (QSM) destination. When whole-volume reallocation is performed with the -p option and snapshots exist an extra redirection step is performed to eliminate this degradation.
The -u option specifies that blocks that are shared by deduplication will be unshared. This option can help remove fragmentation caused on dense volumes. This may result in increased disk usage, especially for full reallocation.
You cannot use the -u option with the -p option.
reallocate start -f [-p] [-u] pathname | /vol/volname
The -f (force) option performs a one-time full reallocation of a file, LUN or an entire volume. A forced reallocation will rewrite blocks in the file, LUN or volume unless the change is predicted to result in worse performance.
If a reallocation job already exists for the path_name it will be stopped, and then restarted as a full reallocation scan. After the reallocation scan completes the job will revert to its previous schedule. If the job was previously quiesced, it will no longer be quiesced.
When doing full reallocation the active filesystem layout may diverge significantly from the data stored in any snapshots. Because of this, volumelevel full reallocation may not be started on volumes that have existing snapshots unless the -p (use physical reallocation) is also used. Please see above for a description of the -p option.
reallocate start -A [-i interval] [-o] aggr
Perform reallocation on the aggregate aggr. Aggregate level reallocation optimizes the location of physical blocks in the aggregate to improve contiguous freespace in the aggregate.
Aggregate snapshots should be deleted prior to running aggregate reallocation. Blocks in an aggregate snapshot will not be reallocated.
Do not use -A after growing an aggregate if you wish to optimize the layout of existing data; instead use `reallocate start -f /vol/<volname>' for each volume in the aggregate.
reallocate stop pathname | aggr
Request that a reallocation job on the LUN or file indicated by pathname, or the indicated aggregate aggr, should be stopped. The stop subcommand will also persistently remove any reallocation job information for pathname, for example scheduled jobs that are not running or jobs that are quiesced.
reallocate status [-v] [pathname | aggr]
Display reallocation status. If pathname is given then only the status for that LUN, file or volume will be displayed. If aggr is given then only the status for that aggregate will be displayed. If no pathname or aggr is given then the status for all reallocation jobs is displayed.
If -v (verbose) is used then more verbose output is used.
reallocate schedule [-d] [-s schedule] pathname | aggr
Set or delete the schedule to run an existing reallocation job for pathname or aggr. (If the reallocation job does not already exist, use reallocate start first to create the job.) The -s option sets a new schedule, specified by schedule. The -d option deletes an existing schedule.
The format for schedule is a single string with four fields:
"minute hour dayofmonth dayofweek"
The wild card "*" in a field means all values for the field. Each field may be expressed as a single value or a comma-separated list.
minute can be a value from 0 to 59.
hour can be a value from 0 (midnight) to 23 (11 pm).
dayofmonth can be a value from 1 to 31.
dayofweek can be a value from 0 (Sunday) to 6 (Saturday).
When a schedule is deleted the previous execution interval set when reallocate start was issued will be restored.
reallocate quiesce pathname | aggr
Quiesce (temporarily stop) any running reallocation job on LUN or file pathname, preserving persistent state so that the job may be started again later, using reallocate restart.
reallocate restart [-i] pathname | aggr
Restart a reallocation job on pathname or aggr. If the job was quiesced, it becomes no longer quiesced. If the job was idle (not yet time to be run again) it will immediately be scheduled to run.
Some jobs will checkpoint their position and will restart where they left off. A checkpoint will be preserved when using reallocate quiesce, but not when using reallocate stop. The -i option will ignore the checkpoint and will start the job at the beginning. (Currently, this is only useful for the first part of aggregate reallocation.)
reallocate measure [-l logfile] [-t threshold] [-i inter_val] [-o] pathname | /vol/volname
Start a measure-only reallocation on the LUN, large file or volume.
A measure-only reallocation job is similar to a normal reallocation job except that only the check phase is performed. This allows the optimization of the LUN, large file or volume to be tracked over time, or measured ad-hoc.
At the end of each check the optimization is logged via EMS. Additionally, for repeating measure-only jobs the optimization of the previous check is saved and may be viewed by running reallocate status. If a logfile is specified, detailed information about the layout is recorded in the file.
The measure job will be run periodically at a system-defined interval. The interval between runs may be changed with the -i (interval) option. The interval is specified as a number of minutes, hours, or days; NNN[mhd]. Note: Depending on the system configuration and write/read workload, it may be appropriate to have the job run at a close interval or at a long interval. If the -o (once) option is used, the job will be run only once, and then automatically removed from the system.
The threshold when a LUN, file or volume is considered unoptimized enough that a reallocation should be performed is given as a number from 3 (moderately optimized) to 10 (very unoptimized). For users of the wafl scan measure_layout command these thresholds are comparable with the ratio output. The default threshold is 4. When the optimization becomes worse than this level the diagnostic logged changes to indicate reallocation may be useful.
Check the LUN /vol/db1/lun1 allocation periodically.
reallocate schedule -s "0 23 * 6" /vol/db/lun1
Schedule a reallocation job at 11 pm every Saturday.
reallocate start -A -o big_aggr
Start a one-time optimization of an aggregate.
reallocate measure -o -l /vol/logs/measure_log_dblun /vol/dbvol/dblun
Measure the optimization of a LUN once, recording detailed information about the measurement in a log.
Aggregate reallocation does not change the logical layout of individual files within the flexible volumes of that aggregate. Thus, it may be appropriate to use both aggregate and file/volume reallocation for best results.
Aggregate reallocation is not supported on aggregates created prior to Data ONTAP 7.2.
Removing a large file or LUN will not remove any reallocation job created on the file or LUN. Instead the reallocation job will suspend until either the file or LUN is recreated, or the reallocation job is destroyed.
Renaming or destroying an entire volume or aggregate will rename or destroy all reallocation jobs associated with that volume or aggregate.
A large directory may also be reallocated, in this case specify the full path for the directory.
Table of Contents