Shadow File System Semantics During Migration
If the client accesses a file or directory that has not yet been migrated, there
is an observable effect on behavior:
-
For directories, clients requests are blocked until the entire directory
is migrated. For files, only the portion of the file being requested is
migrated, and multiple clients can migrate different portions of a file at
the same time.
-
Files and directories can be arbitrarily renamed, removed, or overwritten
on the shadow filesystem without any effect on the migration process.
-
For files that are hard links, the hard link count may not match the
source until the migration is complete.
-
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 ZFSSA 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
affect.
-
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.