Table of Contents
Advertisement
Local - file:///<path>
■
NFS - nfs://<host>/<path>
■
The BUI also allows the alternate form <host>:/<path> for NFS mounts, which matches the
syntax used in UNIX systems. The BUI also sets the protocol portion of the setting (file:// or
nfs://) via the use of a pull down menu. When creating a filesystem, the server will verify that
the path exists and can be mounted.
Managing Background Migration
When a share is created, it will automatically begin migrating in the background, in addition to
servicing inline requests. This migration is controlled by the shadow migration service. There
is a single global tunable, which is the number of threads dedicated to this task. Increasing the
number of threads will result in greater parallelism at the expense of additional resources.
The shadow migration service can be disabled, but this should only be used for testing
purposes, or when the active of shadow migration is overwhelming the system to the point
where it needs to be temporarily stopped. When the shadow migration service is disabled,
synchronous requests are still migrated as needed, but no background migration occurs. With
the service disabled, no shadow migration will ever complete, even if all the contents of the
filesystem are read manually. It is highly recommended to always leave the service enabled.
Handling Migration Errors
Because shadow migration requires committing new writes to the server prior to migration
being complete, it is very important to test migration and monitor for any errors. Errors
encountered during background migration are kept and displayed in the BUI as part of shadow
migration status. Errors encountered during other synchronous migration are not tracked, but
will be accounted for once the background process accesses the affected file. For each file, the
remote filename as well as the specific error are kept. Clicking on the information icon next to
the error count will bring up this detailed list. The error list is not updated as errors are fixed,
but simply cleared by virtue of the migration completing successfully.
Shadow migration will not complete until all files are migrated successfully. If there are errors,
the background migration will continually retry the migration until it succeeds. This allows the
administrator to fix any errors (such as permission problems), let the migration complete, and
be assured of success. If the migration cannot complete due to persistent errors, the migration
can be canceled, leaving the local filesystem with whatever data was able to be migrated. This
should only be used as a last resort; once migration has been canceled, it cannot be resumed.
Managing Background Migration
Shadow Migration
431
Advertisement
Table of Contents
