Last updated on OCTOBER 04, 2016
Applies to:Oracle Hierarchical Storage Manager (HSM) and StorageTek QFS Software - Version 6.0 and later
Information in this document applies to any platform.
The issue occurs when HSM file systems are mounted via NFSv3 to Linux clients. Those clients were having numerous issues when running "ls -l" in their directory (that produces Input/Output errors) as well as failures when copying files onto the NFS share - touching a file worked, and writing to an existing file worked, but trying to do both at the same time (cp, mv, output redirect from ">", etc.) only created an empty file.
Some of the conditions:
1) When the HSM file systems are mounted via NFSv3 to Linux NFS clients (NOTE: these are *NOT* shared SAM-FS clients, they are simple Linux servers that use NFS to mount the HSM file system onto a local directory), then users cannot create and write to files at the same time.
2) When the HSM file systems are mounted via NFSv2 to Linux NFS clients, then all appears to work fine.
3) When the HSM file systems are mounted via NFSv4 to Linux NFS clients, there are no create/write issues, but all files appear to be owned by nobody:nobody.
4) When the HSM file systems are mounted via NFSv3 to Linux NFS clients that use the "noacl" mount flag, then everything works fine (with the obvious exception that ALS are no longer permitted). The errors when running "ls -l" were due to the Linux systems calling for the value of posix_acl_access.
An strace on a Linux client produced the following:
5) Issue appears related to HSM 6.0, because the Linux clients can mount a directory on the ZFS root pool of the SAM server itself, then everything worked fine.
Customer site migrated the Oracle HSM environment, replaced x4600M2 servers running SAM-FS 5.3 in Solaris 10 x86 with X5-2L servers running HSM 6.0 in Solaris 11.2.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
Million Knowledge Articles and hundreds of Community platforms