oracle/graal · error · UnsupportedOperationException

Error setting up DirectIO

Error message

Error setting up DirectIO

What it means

This sun.nio.ch.FileDispatcherImpl substitution maps setDirectIO onto a native call; when the native setDirect0 throws IOException (filesystem does not support O_DIRECT, invalid alignment, etc.), it is wrapped in UnsupportedOperationException('Error setting up DirectIO'). Guest code using DirectByteBuffer/FileChannel with DIRECT I/O on unsupported storage gets this instead of the raw IOException.

Source

Thrown at espresso/src/com.oracle.truffle.espresso.io/src/sun/nio/ch/FileDispatcherImpl.java:102

    }

    @Override
    boolean transferToDirectlyNeedsPositionLock() {
        return false;
    }

    @Override
    boolean canTransferToFromOverlappedMap() {
        return false;
    }

    @Override
    int setDirectIO(FileDescriptor fd, String path) {
        int result = -1;
        try {
            result = setDirect0(fd, path);
        } catch (IOException e) {
            throw new UnsupportedOperationException("Error setting up DirectIO", e);
        }
        return result;
    }

    @Override
    int read(FileDescriptor fd, long address, int len) throws IOException {
        return truffleDispatcher.read(fd, address, len);
    }

    @Override
    long readv(FileDescriptor fd, long address, int len) throws IOException {
        return truffleDispatcher.readv(fd, address, len);
    }

    @Override
    int write(FileDescriptor fd, long address, int len) throws IOException {
        return truffleDispatcher.write(fd, address, len);
    }

View on GitHub (pinned to a66e9ccd1d)

Solutions

  1. Fall back to non-direct I/O: open the channel without ExtendedOpenOption.DIRECT when UnsupportedOperationException is thrown.
  2. Run the workload on a filesystem supporting O_DIRECT (ext4/xfs on a real block device, not tmpfs/overlay).
  3. Ensure buffer and file offsets are aligned to the filesystem's block size if DIRECT must be used.

Example fix

// before
FileChannel ch = FileChannel.open(p, StandardOpenOption.READ, ExtendedOpenOption.DIRECT); // throws on tmpfs

// after
FileChannel ch;
try {
    ch = FileChannel.open(p, StandardOpenOption.READ, ExtendedOpenOption.DIRECT);
} catch (UnsupportedOperationException e) {
    ch = FileChannel.open(p, StandardOpenOption.READ); // buffered fallback
}
Defensive patterns

Strategy: fallback

Try / catch

try {
    ch = FileChannel.open(p, READ, ExtendedOpenOption.DIRECT);
} catch (UnsupportedOperationException e) {
    if (e.getMessage().equals("Error setting up DirectIO")) {
        ch = FileChannel.open(p, READ); // fallback to buffered I/O
    } else throw e;
}

Prevention

When it happens

Trigger: Guest Java code opening a FileChannel with ExtendedOpenOption.DIRECT and the underlying FS (e.g. tmpfs, network FS, or a file on overlayfs in containers) rejecting O_DIRECT; alignment requirements not met by buffer/address.

Common situations: Databases and storage engines (RocksDB-style code paths) enabling DIRECT I/O inside containers/overlay filesystems or on macOS/tmpfs where O_DIRECT is unsupported.

Related errors


AI-assisted analysis of oracle/graal@a66e9ccd1d (2026-08-14). Data as JSON: /api/errors/ff236a34d02f0a8b. Report an issue: GitHub.