+.B all_char (type 1)
+Sum of ASCII characters modulo number of MDTs. This
+provides weak hashing of the filename, and is suitable
+for only testing or when the input is known to have
+perfectly uniform distribution (e.g. sequential numbers).
+.TP
+.B fnv_1a_64 (type 2)
+Fowler-Noll-Vo (FNV-1a) hash algorithm. This provides
+reasonably uniform, but not cryptographically strong,
+hashing of the filename. (default)
+.TP
+.B crush (type 3)
+CRUSH hash algorithm. This is a consistent hash
+algorithm, so minimum sub files need to relocate
+during directory restripe.
+.RE
+.P
+.TP
+.B NOTE
+Only the root user can migrate directories. Files that have been archived by
+HSM or are currently opened will fail to migrate, user can run the same migrate
+command again to finish migration when files are ready. Both inode and
+directory entry will be migrated. During migration directory and sub files can
+be accessed like normal ones, but the migration itself cannot be interrupted.
+.TP
+.B NOTE
+It is not currently possible to migrate files with an
+.B mdt
+component (Data-on-MDT, DoM). If it is necessary to migrate such files off
+a particular MDT, they must first be migrated to have a non-DoM file layout
+and then the inodes migrated separately. See
+.B EXAMPLES
+for details on how to migrate DoM files between MDTs.
+.TP
+.B WARNING
+Each migrated file or directory will have a new FID, and hence a new inode
+number. As a consequence, files archived by Lustre HSM that depend on
+the FID as the identifier in the HSM archive cannot currently be migrated.
+Having a new inode number may also cause backup tools to consider the
+migrated file(s) to be a new, and cause them to be backed up again.
+.P
+.SH EXAMPLES