The LTS system has been migrated from StrongBox Appliance to our new StrongLink environment in July 2022.
New system names are:
lts12 ( replaces lts11 )
lts22 ( replaces lts21 )
NFS Share Mounts
ETH / StrongLink NFS Shares / Client Advisory for mount of StrongLink NFS Shares - 14/09/22 ( StrongLink Data Solutions )
Additional comment ( ETH ): "showmount -e lts12" / "showmount -e lts22" will show the correct names to be used for mount.
Mount of NFS shares is only possible for registered hosts. For registration of new hosts on your share please open a ticket with DBR support.
Write operations are only possible on primary shares.
The following NFSv4 mount options are currently not supported ( see Client Advisory further up )
Syntax examples below are with primary share names, depending on where your primary share is located, you need to use lts12 or lts22 ( same as on the old system ).
Usually replica shares will not be mounted. If you need to mount them just replace primary / secondary share-names accordingly.
Example for Primary Share on lts12 ( former lts11 )
mount -t nfs lts12:/your_primary_share_name -o vers=4.1,rsize=1048576,wsize=1048576 /mount_point
Example for Primary Share on lts22 ( former lts21 )
mount -t nfs lts22:/your_primary_share_name -o vers=4.1,rsize=1048576,wsize=1048576 /mount_point
Fstab entry ( see client advisory above, NFSv4 not supported any more, please use nfs3 )
lts12.ethz.ch:/your_primary_share /your_mount_point nfs4 vers=4.1,rsize=1048576,wsize=1048576,noauto
lts22.ethz.ch:/your_primar_share /your_mount_point nfs4 vers=4.1,rsize=1048576,wsize=1048576,noauto
lts11 / lts21 ( old system ): path:/shares/primary_share_name → lts12 / lts22 ( new system ): /shares/ in front of the share name is not needed any more for NFS mounts
The following mount options in use for the old LTS system ( StrongBox ) should be replaced by the new ones recommended above.
OLD: mount -t nfs -o hard,intr,retrans=10,timeo=300,rsize=65536,wsize=1048576,vers=3
Showmount is an NFSv3 command and cannot display virtual share names.
For all StrongBox migrated shares:
SMB Share Mounts
Recall of Files
Please take under consideration that the LTS system needs some time to get the files back from tape during a Recall.
The Recall is triggered during the first access, after that a tape will be loaded into a drive in the tape-libarry, and the file(s) will be copied back into the disk cache.
This process takes some time in general, and also depending on the workload of the LTS system.
The file will be copied back completely from tape, we do not keep the first 4MB in the landing_zone like on the old system.
→ this immediately leads to an IO-error, if the file still is on tape.
The file can be copied as soon as it is available in the landing_zone.
Below you find the "best practices" for the different access types during Recalls.
|Only recall of single files reasonable with the Windows Explorer.|
Robocopy is ideal for the recall of multiple files or folders.
The options RETRY and MT:1 should be added as robocopy options.
Retry commands need to be added when using the copy command for cifs mounted shares under Linux ( if used with a script ).
If you run cp command from command line, you need to wait a certain time and retry ( once or multiple times, until the file is available ).
If the file is not fully copied from tape yet, and therefor is not readably for the copy-process, it is possible that you receive an IO-error message.
Please consider the recommendations for robocopy and Linux copy above and add retries to your commands.
Windows Explorer is waiting until the file is available, and copies the file after that.