Change Requests: Known Issues and Fixed Issues

Tasks started with the flexsyncadmin start-task command are exempt from the flexsyncd(8) maximum concurrent task limit. As a result, your system might experience higher than normal system resource usage.

Case sensitive settings (caseInsensitive=false) must be configured on both the source and destination hosts. Otherwise, the destination host will merge two files/directories that match on the identical spelling of a file name, even when the names do not match on case.

Workaround: Configure your target host with the same case sensitivity setting as your source host. See the StorNext Man Pages Reference Guide.

Under the following circumstances, FlexSync might start repeatedly replicating the same content:

• When source file systems are replicated with the auditing feature enabled, the auditing feature will make further changes to the source file system. As a result, FlexSync might interpret the files as candidates for additional replication.
• Read activity in the file system might cause FlexSync to scan for content to replicate.

Both instances usually do not result in additional data transfers by Flexsync. However, under certain circumstances, such as when extended attributes are replicated, this issue can occur.

Workaround: Do not configure a replication task if the auditing feature is enabled on the source file system, or when replicating extended attributes.

Under the following specific circumstances, reverse tasks can overwrite the original source data:

1. Create a replication task.
2. While the task is estimating, suspend it.
3. Create a corresponding reverse task.
4. Start both the original source and corresponding reverse tasks.

Workaround: Do not simultaneously run the original source task and its corresponding reverse task.

When viewing a Task Report, you might see two vertical scroll bars if the browser window is not tall enough to display all of the line items.

Mixed versions of FlexSync daemons is not supported and results in a communication error.

You must install the same version of FlexSync, or upgrade to the same version of FlexSync on all of the hosts or systems using Flexsync. A newer version of the Flexsync daemon cannot communicate with an older version within a configuration, or on another host or system.

See Considerations for additional information.

The FlexSync Dashboard host status display contains an activity monitor that displays the following information:

• The number of active tasks. For example, 1 / 4 tasks.
• A throughput number in bytes per second. For example, 10 B/sec.
• A count of files being transferred per second. For example, 10 files/sec.

The throughput number shows information about active tasks only, and is updated across the entire running time of the tasks. With multiple tasks that start and finish at different times, the throughput number can be artificially low because it no longer includes one or more tasks that were also consuming resources.

Also, because the information is captured across different tasks and at different points in time within each task and then aggregated at the user interface, it is unlikely to accurately represent the data being transferred at a specific point in time.

These factors combine to make it difficult to determine the real bandwidth consumption until a task completes. At that point, the exact number of bytes transferred and elapsed time of the replication pass are available in the Configure File Replication.

The If needed, select Bandwidth Throttling. option works by providing the requested number of credits each second to be shared among all of the active tasks. If no tasks have run for at least one second, the next task to start finds one second's worth of credits available immediately.

During the first second of replication for that task, it is possible for the task to consume twice the requested bandwidth rate.

Note: This might result in the per-host activity monitor displaying an aggregate throughput higher than the bandwidth limit until more time elapses and that extra second's worth of bandwidth consumption is averaged in across a longer interval.

If you use a managed file system, do not use a directory associated with a storage manager policy as the source path or destination path of a task.

Note: Sub-directories of these directories and their descendants are permitted as source and destination paths.

If you enable debug logging and run a task for an extended period of time, and then attempt to display a task report using the GUI, the progress might continue to spin.

See the flexsyncd man page for information about the debug logging option (--debug | -d).

There is a chance if running the new UUI, after an upgrade from 6.3.1 to 7.0.1 one may need to cycle flexsync in order for the new UUI to connect?

To restart the See the flexsyncd man page for information about the debug logging option (--debug | -d).

If you upgrade FlexSync Application, you need to restart the FlexSync daemons if they were not stopped prior to the upgrade. See Restart the FlexSync Daemons.

In the TSM logs, you might see the following errors:

Workaround:

You can ignore the errors.

When you suspend a task, the operation might require additional time to process because FlexSync is performing asynchronous operations to receive data.

Workaround:

To interrupt the process, restart the flexsyncd daemon.

When you disable the Force Rescanning option, FlexSync forces a full file system scan with every replication pass.

Workaround:

Configure the Force Rescanning option to a high value such as 365 (or greater) days.

If two files from two different checkout directories that contain identical path names, modification times and file sizes are committed at approximately the same time, the first file is successfully committed and synchronized to your S3 repository, whereas the second file is not. This is similar to two users writing to the same file in a file system, except in that case, the second writer succeeds. FlexSync looks to commit the second file, but does nothing because the file appears to have already been committed; the file is not processed and a conflict is not reported.

You might only notice this issue when you view your S3 repository, or check out another directory and inspect the file. If you notice your repository content is not valid, performing another commit process results in no action being taken. FlexSync considers the file to already be committed.

Workaround:

To work around this issue, do one of the following:

• To retain both files:

  • Move the second (non-repository) instance of the file to a new name.

  • Run the /opt/quantum/flexsync/bin/flexsync get command to retrieve the existing file from the repository and place it in the original name.

    Note: You must provide the destination path in the command.

    Example

    /opt/quantum/flexsync/bin/flexsync get flexsync://reponame/path/to/testfile /stornext/site1/checkoutdir/path/to/testfile

  • At the next commit, the renamed file appears to be newly created and that instance of the file is synchronized to your S3 repository with its new name.

• To retain the second instance of the file:

  • Run the touch command to update the modification time (mtime) of the second file.

  • At the next commit, FlexSync acknowledges the file does not match the content in the S3 repository and the file is synchronized to your S3 repository with the same name, effectively replacing the first commit.

If you checkout to a sub-directory within a directory that is already checked out, you might not be able to update or commit data to your S3 repository.

This could also result in additional data (from the sub-directory) that is committed to your S3 repository if you attempt to commit at the top-level directory.

Workaround:

Do not perform a checkout process to a sub-directory within a directory that is already checked out.