Oracle Cloud Infrastructure Documentation

32-Bit Application Stops Reading or Writing to a File System

Troubleshoot 32-bit application read/write failure on a file system.

Symptom: After a period of functioning correctly, a 32-bit application suddenly stops reading or writing to a file system. The read/write operations fail with an error such as:

Applications fail to install on FSS mount point: "Value too large for defined data type" - OCI FSS/Mount Target Resources (Doc ID 2672465.1)

The application might also fail to start and encounter errors like the following:

RCV: Value too large for defined data type

Cause: The 32-bit application cannot consume larger file IDs. The File Storage service is designed to work with 64-bit applications, so the file IDs generated by File Storage become too large for legacy applications to consume. More information on file identifier maximum values follows:

  • If the application uses a signed 32-bit integer to store the file identifier, then the maximum value that the application can handle before overflow is 2147483647 (2**(31-1)).
  • If the application uses an unsigned 32-bit integer to store the file identifier, then the maximum value that the application can handle before overflow is 4294967295 (2**(32-1)).
  • If the application uses a signed 64-bit integer to store the file identifer, then the maximum value that the application can handle before overflow is 9223372036854775807 (2**(63-1))

To check the size of new file IDs being generated, open a terminal on a connected instance, and run the following command:

touch <File_Storage_mount_point>/test; ls -i <File_Storage_mount_point>/test

Immediate solution: Set the kernel parameter enable_ino64=0.

Setting nfs.enable_ino64=0 instructs the NFS client to return 32-bit inode numbers for readdir() and stat() system calls (instead of the full 64-bit inode numbers).
Important

This solution requires an instance reboot.
  1. Open a terminal window on the instance as the root user and type the following command to verify the current nfs.enable_ino64=0 setting.
    #  cat /sys/module/nfs/parameters/enable_ino64

    The system should return Y, indicating that 64-bit inodes are enabled.

  2. Run the following command to set nfs.enable_ino64=0. 
    echo "options nfs enable_ino64=0"  > /etc/modprobe.d/nfs.conf
  3. Reboot the instance.

  4. Verify that the setting is updated using the following command:

    #  cat /sys/module/nfs/parameters/enable_ino64

    The system should return N, indicating that 64-bit inodes are disabled and returned to 32-bit.

  5. Verify that the file system is mounted to the instance, or mount the file system. See Mounting File Systems.

Intermediate solution: Create a new file system to use with your legacy 32-bit application. Removing files from the original file system does not reset the file ID generation back to 0, so you must create a new file system to start again with small file IDs. Remember that after a certain amount of time, file IDs will become too large for the 32-bit application.

Note

This solution isn't applicable in all cases, depending on the nature of the application and the files it produces. For example, if you are performing a data refresh that copies files from a production file system to a non-production file system, this option would work. However, for applications with organically growing file systems, this option may not work.

Long-term solution: Upgrade your application to a 64-bit version.