LucidLink is Cloud Collaboration Platform that provides a shared global namespace for its users. LucidLink clients can access this global namespace as a local mount on their workstations. To manage the issue of distance and latency between the local workstation and the cloud storage backing the global namespace, LucidLink uses data prefetching, parallel TCP streams, and local write-back caching to optimize performance when accessing data. To properly use CloudSoda with LucidLink, please follow these steps:
- Set up LucidLink using a File Accessor that points to the LucidLink directory on the system. Trying to access LucidLinks S3 backend using third-party applications is not supported by LucidLink.
- Using a graphical interface for Lucid filespaces will not always permit other users, including root, to view that extension of the fuser. If ownership is correct, you may need to toggle "fuse-allow-other" in the GUI or if using the CLI version, add the
--fuse-allow-otherflag to permit root access to the filespace. For additional details, refer to Link Filespace from the command line and LucidLink systemd installation and management script to set this as the default behavior. - When using CloudSoda to write to a LucidLink filespace, make sure to select the Performance tab and change the Validation Method to Size. If either Recommended or Content is chosen, then CloudSoda will try and validate the files by reading back the data to compare the source and target hashes. When this occurs, it can cause cache thrashing in LucidLink and performance will suffer.
Performance Recommendations:
- It is highly recommended that high performance drives (such as NVME) are used for on-prem CloudSoda agents. Similarly, high performance storage is desired when using CloudSoda agents are running as virtual cloud instances.
- Increasing the cache size from the default 25GB is important if there is a significant amount of duplicate data being transmitted.
Comments
0 comments
Please sign in to leave a comment.