Creating A Shadow Filesystem - Oracle ZFS Storage Appliance Administration Manual

Creating a Shadow Filesystem

The majority of file attributes are migrated when the directory is created, but the on-disk
■
size (st_nblocks in the UNIX stat structure) is not available until a read or write operation is
done on the file. The logical size will be correct, but a du(1) or other command will report a
zero size until the file contents are actually migrated.
If the appliance is rebooted, the migration will pick up where it left off originally. While
■
it will not have to re-migrate data, it may have to traverse some already-migrated portions
of the local filesystem, so there may be some impact to the total migration time due to the
interruption.
Data migration makes use of private extended attributes on files. These are generally not
■
observable except on the root directory of the filesystem or through snapshots. Adding,
modifying, or removing any extended attribute that begins with SUNWshadow will have
undefined effects on the migration process and will result in incomplete or corrupt state. In
addition, filesystem-wide state is stored in the .SUNWshadow directory at the root of the
filesystem. Any modification to this content will have a similar effect.
Once a filesystem has completed migration, an alert will be posted, and the shadow attribute
■
will be removed, along with any applicable metadata. After this point, the filesystem will be
indistinguishable from a normal filesystem.
Data can be migrated across multiple filesystems into a singe filesystem, through the use of
■
NFSv4 automatic client mounts (sometimes called "mirror mounts") or nested local mounts.
Use the following rules to migrate identity information for files, including ACLs:
The migration source and target appliance must have the same name service configuration.
■
The migration source and target appliance must have the same NFSv4 mapid domain
■
The migration source must support NFSv4. Use of NFSv3 is possible, but some loss
■
of information will result. Basic identity information (owner and group) and POSIX
permissions will be preserved, but any ACLs will be lost.
The migration source must be exported with root permissions to the appliance.
■
If you see files or directories owned by "nobody", it likely means that the appliance does
not have name services setup correctly, or that the NFSv4 mapid domain is different. If you
get 'permission denied' errors while traversing filesystems that the client should otherwise
have access to, the most likely problem is failure to export the migration source with root
permissions.
Creating a Shadow Filesystem
The shadow migration source can only be set when a filesystem is created. In the BUI, this is
available in the filesystem creation dialog. In the CLI, it is available as the shadow property. The
property takes one of the following forms:
430 Oracle ZFS Storage Appliance Administration Guide, Release OS8.6.x • September 2016