Every failing sample below is the real model output, with the facts it missed or invented. Trial 0 runs at temperature 0, trials 1 and 2 at 0.7 — so a task passing 1/3 is a sampling-luck pass, not a reliable one. Models are ordered best first. Other technologies: C · Python · Bash · research · how to reproduce.
Setup and model serving are on the models index — including a script-free version using nothing but curl and a compiler; with a server running, this is the exact command that produced the samples below:
# research paper: extract NFS facts from ~2,100 words of RHEL 10 docs
# (distractor paragraphs included), 3 trials, graded by exact fact match
python scripts/eval_research.py --target <model> --trials 3 \
--dump-failures results/failuresServed via llama.cpp CUDA · — tok/s · — GB RAM · coding total 117/126
No failures.
Served via llama.cpp CUDA · — tok/s · — GB RAM · coding total 111/126
No failures.
Served via llama.cpp CUDA · — tok/s · — GB RAM · coding total 108/126
- **NFS with TLS support added (RHEL 10.0)** – NFS now supports TLS encryption for RPC traffic, securing client-server communication. Relies on kernel TLS (kTLS), which is a Technology Preview.
- **NFS client supports larger rsize/wsize (up to 1MB)** – Default and maximum read/write buffer sizes increased to 1,048,576 bytes, improving NFS transfer performance.
- **FS-Cache (NFS client-side caching) documented and supported** – Enables local caching of NFS content via `cachefilesd`, reducing network and server load at potential cost to client performance.
- **NFS mount option `vers` added for compatibility** – Alias for `nfsvers`, included for compatibility with older configurations.
- **ReaR fixed to support IPv6 addresses in nfs:// URLs** – Square brackets around IPv6 addresses in `nfs://` URLs are now handled correctly, preventing backup failures.- **NFS with TLS support added (RHEL 10.0)** – TLS is now fully supported for NFS, encrypting RPC traffic between clients and servers via kernel TLS (kTLS). Improves security; kTLS itself is a Technology Preview.
- **NFS client supports `vers` as alias for `nfsvers` (RHEL 10.0)** – The `vers` mount option is now equivalent to `nfsvers`, included for compatibility. No functional change, but clarifies mount option usage.
- **Default `rsize` and `wsize` increased to 1MB (RHEL 10.0)** – Maximum supported NFS read/write transfer size is now 1,048,576 bytes on both client and server. Can improve NFS throughput for large I/O workloads.
- **FS-Cache (`cachefilesd`) supported for NFS client-side caching (RHEL 10.0)** – Enables local caching of NFS content using the `cachefiles` backend, reducing server load and network usage. Requires ext3/ext4/XFS with extended attributes.
- **IPv6 address support fixed in `nfs://` URLs for ReaR (RHEL 10.0)** – Square brackets around IPv6 addresses in `nfs://` URLs are no longer misinterpreted as shell metacharacters. Fixes backup/restore failures when using IPv6 NFS URLs.- **NFS with TLS support added (RHEL 10.0)** – TLS is now fully supported for NFS, encrypting RPC traffic between clients and servers via kernel TLS (kTLS). Improves security; kTLS itself is a Technology Preview.
- **NFS client supports `vers` as alias for `nfsvers` (RHEL 10.0)** – The `vers` mount option is now equivalent to `nfsvers`, included for compatibility. No functional change, but clarifies mount option usage.
- **Default `rsize` and `wsize` increased to 1MB (RHEL 10.0)** – Maximum supported NFS read/write transfer size is now 1,048,576 bytes on both client and server. Can improve NFS throughput for large I/O workloads.
- **FS-Cache (`cachefilesd`) supported for NFS client-side caching (RHEL 10.0)** – Enables local caching of NFS content using the `cachefiles` backend, reducing server load and network usage. Requires ext3/ext4/XFS with extended attributes.
- **IPv6 address support fixed in `nfs://` URLs for ReaR (RHEL 10.0)** – Square brackets around IPv6 addresses in `nfs://` URLs are no longer misinterpreted as shell metacharacters. Fixes backup/restore failures when using IPv6 NFS URLs.Served via llama.cpp CUDA · — tok/s · — GB RAM · coding total 105/126
No failures.
Served via llama.cpp CUDA · — tok/s · — GB RAM · coding total 105/126
No failures.
Served via llama.cpp CUDA · — tok/s · — GB RAM · coding total 105/126
- **NFS with TLS support added** – NFS traffic can now be encrypted using TLS (via kernel TLS/kTLS), improving security for RPC communication between clients and servers. This is a Technology Preview feature in RHEL 10.
- **Default `rsize` and `wsize` increased to 1,048,576 bytes** – Improves NFS read/write performance by allowing larger data transfers per operation, reducing overhead.
- **FS-Cache (client-side caching) for NFS now documented** – Enables local caching of NFS content via `cachefilesd` and supported filesystems (XFS, ext3, ext4), reducing network load and improving read performance at the cost of potential client-side slowdown.
- **IPv6 address support in NFS URLs fixed in ReaR** – Previously, IPv6 addresses in `nfs://` or `sshfs://` URLs (e.g., `nfs://[2001:db8::1]/path`) caused ReaR to fail; now properly parsed, enabling correct backup/restore workflows over IPv6.
- **FS-Cache requires `cachefilesd` service and compatible backend** – To use NFS caching, administrators must configure `/var/cache/fscache/` on ext3/ext4/XFS with extended attributes; ensures proper cache coherency and performance.Served via llama.cpp CUDA · — tok/s · — GB RAM · coding total 105/126
No failures.
Served via llama.cpp CUDA · — tok/s · — GB RAM · coding total 102/126
- **NFS with TLS support (new feature)** – RPC traffic is now encrypted, giving clients and servers end‑to‑end confidentiality. The added cryptographic overhead can slightly reduce throughput, but the feature is essential for secure deployments.
- **Fixed IPv6 address parsing in `nfs://` URLs (bug fix)** – ReaR and other tools that use `nfs://[IPv6]` URLs no longer abort; IPv6 addresses can now be specified in backup/restore URLs, improving reliability of NFS mounts over IPv6.
- **Default `rsize`/`wsize` increased to 1 048 576 bytes (performance improvement)** – The client and server now negotiate a larger transfer block size by default, reducing the number of round‑trips for large reads/writes and boosting overall NFS throughput.
- **FS‑Cache support for NFS (new feature)** – Clients can enable the `cachefiles` back‑end (`cachefilesd` daemon) to cache NFS data locally. This reduces network traffic and server load, improves read performance, and provides persistence across reboots (requires a block‑based FS with extended attributes such as XFS, ext3, or ext4).- **NFS with TLS support** – New feature in RHEL 10.0 that encrypts RPC traffic between NFS clients and servers. It adds a security layer (requiring kernel‑TLS tech preview) and can affect performance by introducing encryption overhead, but it protects data in transit.
- **IPv6 address parsing bug fix for `nfs://` URLs** – Fixed in RHEL 10.0 so that IPv6 addresses enclosed in square brackets are correctly interpreted in `nfs://` URLs (e.g., `nfs://[2001:db8::1]/share`). This resolves a connectivity issue that caused ReaR and other tools to abort when using IPv6 NFS URLs.
- **Default `rsize`/`wsize` increased to 1 MiB** – RHEL 10 now defaults the maximum read/write block size to 1,048,576 bytes (the largest value supported by both client and server). Larger transfer units reduce the number of round‑trips for large files, improving NFS throughput.
- **FS‑Cache client‑side caching** – RHEL 10 introduces FS‑Cache support for NFS, enabling the `cachefiles` back‑end and `cachefilesd` daemon. Cached data is served locally, reducing network traffic and server load, which can boost performance for read‑heavy workloads. The trade‑off is that the client may experience slower I/O for cache misses or when the cache is full, and the cache requires a block‑based file system (XFS, ext3, ext4) with extended attributes.- **NFS with TLS support** – New feature in RHEL 10.0 that encrypts RPC traffic between NFS clients and servers. It adds a security layer (requiring kernel‑TLS tech preview) and can affect performance by introducing encryption overhead, but it protects data in transit.
- **IPv6 address parsing bug fix for `nfs://` URLs** – Fixed in RHEL 10.0 so that IPv6 addresses enclosed in square brackets are correctly interpreted in `nfs://` URLs (e.g., `nfs://[2001:db8::1]/share`). This resolves a connectivity issue that caused ReaR and other tools to abort when using IPv6 NFS URLs.
- **Default `rsize`/`wsize` increased to 1 MiB** – RHEL 10 now defaults the maximum read/write block size to 1,048,576 bytes (the largest value supported by both client and server). Larger transfer units reduce the number of round‑trips for large files, improving NFS throughput.
- **FS‑Cache client‑side caching** – RHEL 10 introduces FS‑Cache support for NFS, enabling the `cachefiles` back‑end and `cachefilesd` daemon. Cached data is served locally, reducing network traffic and server load, which can boost performance for read‑heavy workloads. The trade‑off is that the client may experience slower I/O for cache misses or when the cache is full, and the cache requires a block‑based file system (XFS, ext3, ext4) with extended attributes.Served via llama.cpp CUDA · — tok/s · — GB RAM · coding total 102/126
No failures.
Served via llama.cpp CUDA · — tok/s · — GB RAM · coding total 99/126
No failures.
Served via llama.cpp CUDA · — tok/s · — GB RAM · coding total 99/126
* **NFS with TLS support is fully supported**: NFS now supports Transport Layer Security (TLS) for RPC traffic, enabling encrypted communication between clients and servers. This matters because it enhances security by protecting data in transit, though it relies on kernel TLS (kTLS), which is currently a Technology Preview.
* **ReaR NFS URL parsing fixed for IPv6**: The ReaR backup tool now correctly interprets square brackets in `nfs://` URLs containing IPv6 addresses. This matters because it allows users to specify IPv6 NFS servers in `BACKUP_URL` or `OUTPUT_URL` without requiring complex shell escaping workarounds that previously caused premature aborts.
* **Increased default maximum for rsize and wsize**: In RHEL 10, the maximum supported value for NFS read (`rsize`) and write (`wsize`) operations is 1,048,576 bytes. This matters because larger transfer sizes can improve throughput and performance for both NFS clients and servers compared to previous defaults.
* **FS-Cache integration for NFS client performance**: NFS clients can leverage FS-Cache (via the `cachefiles` backend) to cache content locally. This matters because it can significantly reduce network bandwidth usage and server load by satisfying read requests from local storage, although it may introduce slight latency overhead on the client side.* **NFS with TLS support is fully supported**: NFS now supports Transport Layer Security (TLS) for RPC traffic, enabling encrypted communication between clients and servers. This matters because it enhances security by protecting data in transit, though it relies on kernel TLS (kTLS), which is currently a Technology Preview.
* **ReaR NFS URL parsing fixed for IPv6**: The ReaR backup tool now correctly interprets square brackets in `nfs://` URLs containing IPv6 addresses. This matters because it allows users to specify IPv6 NFS servers in `BACKUP_URL` or `OUTPUT_URL` without requiring complex shell escaping workarounds that previously caused premature aborts.
* **Increased default maximum for rsize and wsize**: In RHEL 10, the maximum supported value for NFS read (`rsize`) and write (`wsize`) operations is 1,048,576 bytes. This matters because larger transfer sizes can improve throughput and performance for both NFS clients and servers compared to previous defaults.
* **FS-Cache integration for NFS client performance**: NFS clients can leverage FS-Cache (via the `cachefiles` backend) to cache content locally. This matters because it can significantly reduce network bandwidth usage and server load by satisfying read requests from local storage, although it may introduce slight latency overhead on the client side.* **NFS with TLS support is fully supported**: NFS now supports Transport Layer Security (TLS) for RPC traffic, enabling encrypted communication between clients and servers. This matters because it enhances security by protecting data in transit, though it relies on kernel TLS (kTLS), which is currently a Technology Preview.
* **ReaR NFS URL parsing fixed for IPv6**: The ReaR backup tool now correctly interprets square brackets in `nfs://` URLs containing IPv6 addresses. This matters because it allows users to specify IPv6 NFS servers in `BACKUP_URL` or `OUTPUT_URL` without requiring complex shell escaping workarounds that previously caused premature aborts.
* **Increased default maximum for rsize and wsize**: In RHEL 10, the maximum supported value for NFS read (`rsize`) and write (`wsize`) operations is 1,048,576 bytes. This matters because larger transfer sizes can improve throughput and performance for both NFS clients and servers compared to previous defaults.
* **FS-Cache integration for NFS client performance**: NFS clients can leverage FS-Cache (via the `cachefiles` backend) to cache content locally. This matters because it can significantly reduce network bandwidth usage and server load by satisfying read requests from local storage, although it may introduce slight latency overhead on the client side.Served via llama.cpp CUDA · — tok/s · — GB RAM · coding total 96/126
No failures.
Served via llama.cpp CUDA · — tok/s · — GB RAM · coding total 96/126
* **NFS with TLS support is fully supported**: Enables Transport Layer Security (TLS) for RPC traffic to ensure encrypted communication between clients and servers. This matters for enhancing NFS security, though it relies on kernel TLS (kTLS) which is currently a Technology Preview.
* **ReaR correctly parses IPv6 addresses in NFS URLs**: Fixes a bug where square brackets in IPv6 addresses (e.g., `nfs://[::1]/...`) were interpreted as shell metacharacters, causing ReaR to abort. This matters because it allows users to correctly use IPv6 addresses in NFS backup and output URLs without manual workarounds.
* **Default `rsize` and `wsize` increased to 1,048,576 bytes**: The maximum number of bytes for single NFS read/write operations is now 1 MB (up from previous defaults). This matters because it allows for larger data transfers per operation, potentially improving throughput and performance for NFS mounts.
* **NFS client-side caching via FS-Cache is documented and supported**: Introduces support for leveraging FS-Cache to cache NFS content locally. This matters because it can improve performance by reducing network latency and server load, allowing efficient local data retrieval for read requests.
* **FS-Cache requires specific back-end file systems**: FS-Cache now requires the cache back-end (mounted at `/var/cache/fscache/`) to be XFS, ext3, or ext4 with extended attributes. This matters for performance configuration, as using unsupported file systems will prevent the caching mechanism from functioning.* **NFS with TLS support is fully supported**: Enables Transport Layer Security (TLS) for RPC traffic to ensure encrypted communication between clients and servers. This matters for enhancing NFS security, though it relies on kernel TLS (kTLS) which is currently a Technology Preview.
* **ReaR correctly parses IPv6 addresses in NFS URLs**: Fixes a bug where square brackets in IPv6 addresses (e.g., `nfs://[::1]/...`) were interpreted as shell metacharacters, causing ReaR to abort. This matters because it allows users to correctly use IPv6 addresses in NFS backup and output URLs without manual workarounds.
* **Default `rsize` and `wsize` increased to 1,048,576 bytes**: The maximum number of bytes for single NFS read/write operations is now 1 MB (up from previous defaults). This matters because it allows for larger data transfers per operation, potentially improving throughput and performance for NFS mounts.
* **NFS client-side caching via FS-Cache is documented and supported**: Introduces support for leveraging FS-Cache to cache NFS content locally. This matters because it can improve performance by reducing network latency and server load, allowing efficient local data retrieval for read requests.
* **FS-Cache requires specific back-end file systems**: FS-Cache now requires the cache back-end (mounted at `/var/cache/fscache/`) to be XFS, ext3, or ext4 with extended attributes. This matters for performance configuration, as using unsupported file systems will prevent the caching mechanism from functioning.* **NFS with TLS support is fully supported**: Enables Transport Layer Security (TLS) for RPC traffic to ensure encrypted communication between clients and servers. This matters for enhancing NFS security, though it relies on kernel TLS (kTLS) which is currently a Technology Preview.
* **ReaR correctly parses IPv6 addresses in NFS URLs**: Fixes a bug where square brackets in IPv6 addresses (e.g., `nfs://[::1]/...`) were interpreted as shell metacharacters, causing ReaR to abort. This matters because it allows users to correctly use IPv6 addresses in NFS backup and output URLs without manual workarounds.
* **Default `rsize` and `wsize` increased to 1,048,576 bytes**: The maximum number of bytes for single NFS read/write operations is now 1 MB (up from previous defaults). This matters because it allows for larger data transfers per operation, potentially improving throughput and performance for NFS mounts.
* **NFS client-side caching via FS-Cache is documented and supported**: Introduces support for leveraging FS-Cache to cache NFS content locally. This matters because it can improve performance by reducing network latency and server load, allowing efficient local data retrieval for read requests.
* **FS-Cache requires specific back-end file systems**: FS-Cache now requires the cache back-end (mounted at `/var/cache/fscache/`) to be XFS, ext3, or ext4 with extended attributes. This matters for performance configuration, as using unsupported file systems will prevent the caching mechanism from functioning.Served via llama.cpp CUDA · — tok/s · — GB RAM · coding total 94/126
No failures.
Served via llama.cpp CUDA · — tok/s · — GB RAM · coding total 93/126
No failures.
Served via llama.cpp CUDA · — tok/s · — GB RAM · coding total 93/126
- **NFS with TLS support added**: RHEL 10 now fully supports Transport Layer Security (TLS) for NFS, enabling encrypted RPC traffic between clients and servers. This matters by significantly enhancing security against traffic sniffing and tampering, though it relies on the kernel TLS (kTLS) feature which is currently a Technology Preview.
- **IPv6 address handling in NFS URLs fixed**: The ReaR backup tool now correctly interprets IPv6 addresses enclosed in square brackets (e.g., `nfs://[::1]/path`) within `BACKUP_URL` or `OUTPUT_URL` parameters. This matters because it resolves a bug where the tool previously aborted with an "Invalid scheme" error, allowing automated backups to NFS shares using IPv6 without requiring manual workarounds.
- **NFS client-side caching (FS-Cache) capabilities**: The documentation details the use of FS-Cache with NFS to improve performance by caching data locally on the client. This matters because it reduces network bandwidth consumption and server load by satisfying read requests from the local cache, though it may introduce a slight performance overhead on the client side depending on the workload.
- **Default maximum read/write sizes defined**: In RHEL 10, the default maximum values for `rsize` and `wsize` (data transfer sizes) are set to 1,048,576 bytes (1 MiB) for both client and server. This matters for performance tuning as it ensures the system automatically negotiates the largest possible data transfer size supported by both ends, optimizing throughput for large file operations.
- **NFS mount option `port` behavior clarified for NFSv4**: For NFSv4, if the `port` option is not specified, the client now uses the standard TCP port 2049 and skips querying the `rpcbind` service. This matters for connection reliability and speed, as it reduces dependency on the `rpcbind` service for NFSv4 mounts, which typically use a fixed port.- **NFS with TLS support added**: RHEL 10 now fully supports Transport Layer Security (TLS) for NFS, enabling encrypted RPC traffic between clients and servers. This matters by significantly enhancing security against traffic sniffing and tampering, though it relies on the kernel TLS (kTLS) feature which is currently a Technology Preview.
- **IPv6 address handling in NFS URLs fixed**: The ReaR backup tool now correctly interprets IPv6 addresses enclosed in square brackets (e.g., `nfs://[::1]/path`) within `BACKUP_URL` or `OUTPUT_URL` parameters. This matters because it resolves a bug where the tool previously aborted with an "Invalid scheme" error, allowing automated backups to NFS shares using IPv6 without requiring manual workarounds.
- **NFS client-side caching (FS-Cache) capabilities**: The documentation details the use of FS-Cache with NFS to improve performance by caching data locally on the client. This matters because it reduces network bandwidth consumption and server load by satisfying read requests from the local cache, though it may introduce a slight performance overhead on the client side depending on the workload.
- **Default maximum read/write sizes defined**: In RHEL 10, the default maximum values for `rsize` and `wsize` (data transfer sizes) are set to 1,048,576 bytes (1 MiB) for both client and server. This matters for performance tuning as it ensures the system automatically negotiates the largest possible data transfer size supported by both ends, optimizing throughput for large file operations.
- **NFS mount option `port` behavior clarified for NFSv4**: For NFSv4, if the `port` option is not specified, the client now uses the standard TCP port 2049 and skips querying the `rpcbind` service. This matters for connection reliability and speed, as it reduces dependency on the `rpcbind` service for NFSv4 mounts, which typically use a fixed port.- **NFS with TLS support added**: RHEL 10 now fully supports Transport Layer Security (TLS) for NFS, enabling encrypted RPC traffic between clients and servers. This matters by significantly enhancing security against traffic sniffing and tampering, though it relies on the kernel TLS (kTLS) feature which is currently a Technology Preview.
- **IPv6 address handling in NFS URLs fixed**: The ReaR backup tool now correctly interprets IPv6 addresses enclosed in square brackets (e.g., `nfs://[::1]/path`) within `BACKUP_URL` or `OUTPUT_URL` parameters. This matters because it resolves a bug where the tool previously aborted with an "Invalid scheme" error, allowing automated backups to NFS shares using IPv6 without requiring manual workarounds.
- **NFS client-side caching (FS-Cache) capabilities**: The documentation details the use of FS-Cache with NFS to improve performance by caching data locally on the client. This matters because it reduces network bandwidth consumption and server load by satisfying read requests from the local cache, though it may introduce a slight performance overhead on the client side depending on the workload.
- **Default maximum read/write sizes defined**: In RHEL 10, the default maximum values for `rsize` and `wsize` (data transfer sizes) are set to 1,048,576 bytes (1 MiB) for both client and server. This matters for performance tuning as it ensures the system automatically negotiates the largest possible data transfer size supported by both ends, optimizing throughput for large file operations.
- **NFS mount option `port` behavior clarified for NFSv4**: For NFSv4, if the `port` option is not specified, the client now uses the standard TCP port 2049 and skips querying the `rpcbind` service. This matters for connection reliability and speed, as it reduces dependency on the `rpcbind` service for NFSv4 mounts, which typically use a fixed port.Served via llama.cpp CUDA · — tok/s · — GB RAM · coding total 93/126
No failures.
Served via llama.cpp CUDA · — tok/s · — GB RAM · coding total 91/126
No failures.
Served via llama.cpp CUDA · — tok/s · — GB RAM · coding total 87/126
- **NFS with TLS support** (Technology Preview in RHEL 10):
- NFS now supports TLS for RPC traffic to encrypt communication between clients and servers.
- Matters for secure and encrypted NFS operations, though performance impact may be higher due to encryption overhead.
- **RHEL 10 Managing file systems — Common NFS mount options**:
- `rsize=num` and `wsize=num`:
- Default and maximum values increased to 1,048,576 bytes (1 MiB).
- Why: Larger read/write sizes reduce network overhead and improve throughput for NFS operations.
- `sec=krb5p`:
- Uses Kerberos V5 for authentication, integrity checking, and encryption.
- Why: Most secure option, but may introduce performance overhead due to encryption.
- **RHEL 10 Managing file systems — Enabling client-side caching of NFS content**:
- FS-Cache (client-side caching) now supported for NFS to cache data locally.
- Why: Reduces server load and network bandwidth usage, improving performance for repeated reads.
- Cache backends supported: XFS, ext3, ext4.
- Why: These file systems support block mapping and extended attributes required for caching.
- `cachefilesd` service introduced to manage caching.
- Why: Provides a way to configure and manage client-side caching transparently.Served via llama.cpp CUDA · — tok/s · — GB RAM · coding total 82/126
No failures.
Served via llama.cpp CUDA · — tok/s · — GB RAM · coding total 61/126
- **NFS with TLS support**: RHEL 10 offers NFS with Transport Layer Security (TLS), enhancing security by enabling encrypted communication between clients and servers. This feature relies on kernel TLS (kTLS), provided as a Technology Preview.
- **IPv6 address parsing fix**: A bug affecting the use of IPv6 addresses in sshfs:// and nfs:// URLs has been fixed. Now, square brackets around IPv6 addresses are correctly interpreted, allowing their use in these URL schemes.
- **NFS client-side caching**: RHEL 10 introduces client-side caching for NFS using FS-Cache, which can improve performance, reduce server load, and enable efficient local data retrieval. FS-Cache requires a compatible cache back-end file system (XFS, ext3, or ext4) and can be configured using the`/etc/cachefilesd.conf` file.<|END_OF_TURN_TOKEN|>- **NFS with TLS support**: RHEL 10 offers NFS with Transport Layer Security (TLS), enhancing security by enabling encrypted communication between clients and servers. This feature relies on kernel TLS (kTLS), provided as a Technology Preview.
- **IPv6 address parsing fix**: A bug affecting the use of IPv6 addresses in sshfs:// and nfs:// URLs has been fixed. Now, square brackets around IPv6 addresses are correctly interpreted, allowing their use in these URL schemes.
- **NFS client-side caching**: RHEL 10 introduces client-side caching for NFS using FS-Cache, which can improve performance, reduce server load, and enable efficient local data retrieval. FS-Cache requires a compatible cache back-end file system (XFS, ext3, or ext4) and can be configured using the`/etc/cachefilesd.conf` file.<|END_OF_TURN_TOKEN|>- **NFS with TLS support**: RHEL 10 offers NFS with Transport Layer Security (TLS), enhancing security by enabling encrypted communication between clients and servers. This feature relies on kernel TLS (kTLS), provided as a Technology Preview.
- **IPv6 address parsing fix**: A bug affecting the use of IPv6 addresses in sshfs:// and nfs:// URLs has been fixed. Now, square brackets around IPv6 addresses are correctly interpreted, allowing their use in these URL schemes.
- **NFS client-side caching**: RHEL 10 introduces client-side caching for NFS using FS-Cache, which can improve performance, reduce server load, and enable efficient local data retrieval. FS-Cache requires a compatible cache back-end file system (XFS, ext3, or ext4) and can be configured using the`/etc/cachefilesd.conf` file.<|END_OF_TURN_TOKEN|>