Mixed Mode Deployments and Limitations

The AuriStor File System was designed to permit in-place migrations without a flag day. However, there are restrictions and limitations depending on the mix of OpenAFS and AuriStor clients and servers within the cell.

AuriStor Client with AFS Volume Location Server

The AuriStor client when communicating with an AFS Volume Location Server is restricted to AFS capabilities.

  • Enhanced RxGK authentication and AES-256/SHA-1 security are not possible within the cell
  • File Servers must listen on port 7000 and IPv6 cannot be supported

AuriStor Client with AFS File Server

The AuriStor client when communicating with an AFS File Server is restricted to AFS capabilities.

  • Rx performance is better than an AFS client but is degraded
  • RxKAD authentication and FCRYPT wire privacy MUST be used even if the cell supports RxGK
  • Mandatory Security Levels are not enforced
  • Timestamps, Sizes, Volume IDs, and File IDs are restricted
  • Mandatory lock requests are ignored
  • Additional round trips are required for volume status information, locks after create, and other RPCs
  • Quota and volume size information may be faked

AuriStor File Server and AFS Volume Location Server

The AuriStor File Server can be deployed in an OpenAFS cell but is restricted to AFS capabilities.

  • RxGK authentication cannot be enabled
  • File Server must listen on port 7000
  • Volume ID name space restricted to AFS limits
  • Only AFS compatible capabilities can be advertised
  • Security policy requirements cannot be enforced
  • IPv6 addresses cannot be published

AFS File Server and AuriStor Volume Location Server

The AFS file server can be deployed in an AuriStor cell with the following restrictions.

  • File server cannot enforce or advertise mandatory security level requirements
  • File server must listen on port 7000
  • RxGK is unavailable
  • File server cannot host volumes with IDs larger than 232-1
  • File server cannot be a replica site for volumes stored on an AuriStor file server

AFS and AuriStor Volume Server Interoperability

AFS and AuriStor file servers can be deployed within a single cell with the following restrictions.

  • Volumes cannot be replicated from an AuriStor server to an AFS server.
  • Volumes cannot be moved from an AuriStor server to an AFS server if there would be data loss
    • ACL data
    • Volume attributes
    • Directories with more entries than the AFS limits
    • Extended attributes and alternate data streams
  • All data transfers are protected with FCRYPT and not AES-256/SHA-1
  • Rx performance is improved over AFS to AFS but degraded compared to AuriStor to AuriStor

AFS Client and AuriStor Volume Location And File Servers

AFS clients are restricted to the capabilities of the AFS protocol and the RxKAD security class. AFS clients can continue to interoperate within an AuriStor cell provided that the AuriStor servers are not configured to require the use of RxGK, keyed cache managers, combined tokens, or AES-256/SHA-1 wire privacy. In addition, AFS clients experience the following restrictions:

  • Volumes with IDs larger than 232-1 are inaccessible
  • Directories that contains objects with per-object ACLs are inaccessible
  • Directories containing more entries than can be represented in AFS are inaccessible
  • Extended attributes and alternate data streams are hidden. Deletion of the object will delete the extended attributes and alternate data streams without notice
  • Mandatory locks cannot be requested but will be enforced when issued to other clients
  • Read-write volume replicas are unavailable
  • Volume quotas and sizes will be faked if the actual sizes are larger than 231 KBs
  • No ability to enable directory ACL inheritance
  • Other restrictions as required to enforce security policies and prevent data corruption

Ready to migrate from OpenAFS? Contact us to learn more.