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 Metal · 33.0 tok/s · 39.0 GB RAM · coding total 108/126
No failures.
Served via llama.cpp Metal · 61.6 tok/s · 51.7 GB RAM · coding total 106/126
- **NFS with TLS support (kTLS)** – RHEL 10 adds full TLS encryption for NFS RPC traffic. It uses the kernel TLS (kTLS) framework (currently a Technology Preview). Encryption secures data in‑flight and, when kTLS is active, can offload crypto to hardware, reducing CPU overhead compared with userspace TLS.
- **IPv6 address handling in NFS URLs (ReaR bug fix)** – A parsing bug prevented `nfs://[IPv6‑addr]/…` URLs from being accepted by ReaR, causing backup/restore failures. The fix stops the shell from treating the brackets as metacharacters, allowing direct use of IPv6 NFS URLs without work‑arounds.
- **Increased default `rsize`/`wsize` limits** – The client and server now default to a maximum read/write size of **1 048 576 bytes** (up from earlier, lower defaults). Larger I/O chunks improve NFS throughput, especially over high‑latency or high‑bandwidth links.
- **Client‑side NFS caching via FS‑Cache** – RHEL 10 ships the `cachefilesd` daemon and enables the `cachefiles` back‑end for FS‑Cache. When the mount option to use FS‑Cache is set, read requests can be satisfied from a local persistent cache (XFS, ext3/4), dramatically reducing network traffic and server load; the trade‑off is a modest increase in client CPU/IO for cache management.
- **`sec=krb5p` security option noted** – Kerberos 5 with privacy (encryption) is available (`sec=krb5p`). It provides the strongest protection but adds the highest CPU cost, so administrators can weigh security versus performance when choosing NFS security flavors.
- **`vers` mount option added for compatibility** – The alias `vers` (identical to `nfsvers`) is now recognized, simplifying scripts that specify NFS version without affecting performance.Served via llama.cpp Metal · 83.1 tok/s · 11.8 GB RAM · coding total 104/126
- **NFS over TLS support** – RHEL 10 now fully supports NFS with Transport Layer Security (TLS) for RPC traffic. This adds end‑to‑end encryption for NFS clients and servers, improving data confidentiality and compliance, while introducing a modest performance overhead due to TLS processing.
- **Maximum rsize/wsize set to 1 MiB** – The default maximum read/write block size for NFS mounts is now 1,048,576 bytes. Larger block sizes reduce the number of round‑trips for large files, boosting throughput on high‑bandwidth links and lowering latency for bulk I/O.
- **FS‑Cache integration for NFS** – RHEL 10 introduces client‑side caching of NFS data via the FS‑Cache framework (cachefilesd). Cached reads are served locally, cutting network traffic, easing server load, and speeding up repeated access to the same files, at the cost of local storage space.
- **ReaR IPv6 nfs:// URL parsing bug fix** – Fixed a bug where ReaR mis‑parsed IPv6 addresses enclosed in brackets in `nfs://` URLs, causing backup operations to abort. Now IPv6 addresses can be used directly in backup URLs, simplifying configuration and preventing accidental failures.- **NFS over TLS support** – RHEL 10 now fully supports NFS with Transport Layer Security (TLS) for RPC traffic. This adds end‑to‑end encryption for NFS clients and servers, improving data confidentiality and compliance, while introducing a modest performance overhead due to TLS processing.
- **Maximum rsize/wsize set to 1 MiB** – The default maximum read/write block size for NFS mounts is now 1,048,576 bytes. Larger block sizes reduce the number of round‑trips for large files, boosting throughput on high‑bandwidth links and lowering latency for bulk I/O.
- **FS‑Cache integration for NFS** – RHEL 10 introduces client‑side caching of NFS data via the FS‑Cache framework (cachefilesd). Cached reads are served locally, cutting network traffic, easing server load, and speeding up repeated access to the same files, at the cost of local storage space.
- **ReaR IPv6 nfs:// URL parsing bug fix** – Fixed a bug where ReaR mis‑parsed IPv6 addresses enclosed in brackets in `nfs://` URLs, causing backup operations to abort. Now IPv6 addresses can be used directly in backup URLs, simplifying configuration and preventing accidental failures.Served via llama.cpp Metal · 60.7 tok/s · 16.6 GB RAM · coding total 102/126
No failures.
Served via llama.cpp Metal · 14.4 tok/s · 15.6 GB RAM · coding total 102/126
No failures.
Served via llama.cpp Metal · 20.4 tok/s · 70.5 GB RAM · coding total 102/126
No failures.
Served via llama.cpp Metal · 39.7 tok/s · 61.6 GB RAM · coding total 101/126
- **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 without changing core NFS functionality; kTLS itself remains a Technology Preview.
- **NFS client supports larger rsize/wsize values (up to 1MB)** – Default and maximum read/write buffer sizes for NFS mounts increased to 1,048,576 bytes on both client and server. Enhances throughput for large data transfers.
- **NFSv4 mount behavior change for port specification** – When `port` is not specified for NFSv4, the client uses the standard port (TCP 2049) directly instead of querying `rpcbind`. Reduces connection latency and dependency on rpcbind for NFSv4 mounts.
- **ReaR fixed to support IPv6 addresses in nfs:// URLs** – Square brackets around IPv6 addresses in `nfs://` URLs are no longer misinterpreted as shell metacharacters. Enables correct parsing and use of IPv6-based NFS backup locations in ReaR.
- **FS-Cache integration with NFS remains supported** – Client-side caching via FS-Cache and `cachefilesd` continues to be available for NFS, allowing local caching of remote content to reduce server load and network usage. No new changes noted, but confirms ongoing support.- **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 without requiring application changes; kTLS itself remains a Technology Preview.
- **NFS client supports larger rsize/wsize (up to 1MB) (RHEL 10.0)** – Maximum read/write transfer size increased to 1,048,576 bytes for both client and server. Enhances NFS performance by allowing larger data transfers per operation.
- **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. Enables correct use of IPv6 NFS URLs in backup/restore configurations.
- **FS-Cache client-side caching documentation updated (RHEL 10.0)** – Clarifies use of `cachefiles` and `cachefilesd` for NFS caching to improve performance and reduce server load. Helps optimize repeated read workloads by caching remote NFS content locally.- **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 without requiring application changes; kTLS itself remains a Technology Preview.
- **NFS client supports larger rsize/wsize (up to 1MB) (RHEL 10.0)** – Maximum read/write transfer size increased to 1,048,576 bytes for both client and server. Enhances NFS performance by allowing larger data transfers per operation.
- **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. Enables correct use of IPv6 NFS URLs in backup/restore configurations.
- **FS-Cache client-side caching documentation updated (RHEL 10.0)** – Clarifies use of `cachefiles` and `cachefilesd` for NFS caching to improve performance and reduce server load. Helps optimize repeated read workloads by caching remote NFS content locally.Served via llama.cpp Metal · 81.1 tok/s · 16.9 GB RAM · coding total 100/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.
- **FS-Cache integration for NFS client-side caching** – Enables transparent caching of NFS content using FS-Cache and `cachefilesd`, reducing network load and improving performance by serving reads from local cache. Requires a backing filesystem (XFS, ext3, ext4) under `/var/cache/fscache/`.
- **IPv6 address handling in NFS URLs fixed** – ReaR now correctly parses IPv6 addresses enclosed in square brackets in `nfs://` or `sshfs://` URLs (e.g., `nfs://[2001:db8::1]/path`), fixing backup failures caused by improper bracket interpretation.
- **Default `rsize` and `wsize` increased to 1,048,576 bytes** – RHEL 10 clients and servers now use a maximum transfer size of 1MB for NFS reads/writes by default, improving throughput compared to earlier versions.
- **New `vers` mount option for NFS** – Added as an alias for `nfsvers`, improving compatibility with scripts or tools expecting the `vers` syntax.
- **FS-Cache requires extended attributes and block mapping** – FS-Cache for NFS depends on the backing cache filesystem supporting `bmap` and extended attributes (default in XFS, ext3, ext4 on RHEL 8+).Served via llama.cpp Metal · 54.6 tok/s · 45.6 GB RAM · coding total 99/126
No failures.
Served via llama.cpp Metal · 14.8 tok/s · 15.9 GB RAM · coding total 99/126
* **NFS with TLS support**: RHEL 10 fully supports NFS with Transport Layer Security (TLS) to encrypt RPC traffic between clients and servers. This matters for security, though it relies on kernel TLS (kTLS), which is currently a Technology Preview.
* **ReaR NFS URL parsing fix**: The ReaR backup tool now correctly interprets square brackets in `nfs://` URLs containing IPv6 addresses (e.g., `nfs://[2001:db8::1]/share`). Previously, these brackets were misinterpreted as shell metacharacters, causing premature aborts; this fix allows seamless use of IPv6 NFS targets in backup configurations.
* **Increased default rsize/wsize limits**: The maximum supported value for `rsize` and `wsize` (read/write buffer sizes) is now 1,048,576 bytes for both client and server. This matters for performance, as larger transfer sizes can improve throughput for large file operations compared to previous defaults.
* **FS-Cache for NFS performance**: Documentation highlights the use of FS-Cache (via `cachefiles`) to cache NFS content locally. This matters for performance by reducing network bandwidth usage and server load, allowing read requests to be satisfied from local storage, though it may introduce slight latency overhead on the client.* **NFS with TLS support**: RHEL 10 fully supports NFS with Transport Layer Security (TLS) to encrypt RPC traffic between clients and servers. This matters for security, though it relies on kernel TLS (kTLS), which is currently a Technology Preview.
* **ReaR NFS URL parsing fix**: The ReaR backup tool now correctly interprets square brackets in `nfs://` URLs containing IPv6 addresses (e.g., `nfs://[2001:db8::1]/share`). Previously, these brackets were misinterpreted as shell metacharacters, causing premature aborts; this fix allows seamless use of IPv6 NFS targets in backup configurations.
* **Increased default rsize/wsize limits**: The maximum supported value for `rsize` and `wsize` (read/write buffer sizes) is now 1,048,576 bytes for both client and server. This matters for performance, as larger transfer sizes can improve throughput for large file operations compared to previous defaults.
* **FS-Cache for NFS performance**: Documentation highlights the use of FS-Cache (via `cachefiles`) to cache NFS content locally. This matters for performance by reducing network bandwidth usage and server load, allowing read requests to be satisfied from local storage, though it may introduce slight latency overhead on the client.* **NFS with TLS support**: RHEL 10 fully supports NFS with Transport Layer Security (TLS) to encrypt RPC traffic between clients and servers. This matters for security, though it relies on kernel TLS (kTLS), which is currently a Technology Preview.
* **ReaR NFS URL parsing fix**: The ReaR backup tool now correctly interprets square brackets in `nfs://` URLs containing IPv6 addresses (e.g., `nfs://[2001:db8::1]/share`). Previously, these brackets were misinterpreted as shell metacharacters, causing premature aborts; this fix allows seamless use of IPv6 NFS targets in backup configurations.
* **Increased default rsize/wsize limits**: The maximum supported value for `rsize` and `wsize` (read/write buffer sizes) is now 1,048,576 bytes for both client and server. This matters for performance, as larger transfer sizes can improve throughput for large file operations compared to previous defaults.
* **FS-Cache for NFS performance**: Documentation highlights the use of FS-Cache (via `cachefiles`) to cache NFS content locally. This matters for performance by reducing network bandwidth usage and server load, allowing read requests to be satisfied from local storage, though it may introduce slight latency overhead on the client.Served via llama.cpp Metal · 63.1 tok/s · 17.9 GB RAM · coding total 96/126
No failures.
Served via llama.cpp Metal · 58.1 tok/s · 19.1 GB RAM · coding total 96/126
No failures.
Served via llama.cpp Metal · 23.5 tok/s · 16.3 GB RAM · coding total 94/126
No failures.
Served via llama.cpp Metal · 48.4 tok/s · 17.9 GB RAM · coding total 94/126
No failures.
Served via llama.cpp Metal · 52.2 tok/s · 59.7 GB RAM · coding total 91/126
- **NFS with TLS support** (EXCERPT 1):
- NFS now supports fully encrypted communication using TLS for RPC traffic.
- This matters for security but may introduce performance overhead compared to unencrypted NFS.
- **`fstrim` enabled by default on LUKS2 root in ostree-based installations** (EXCERPT 2):
- `fstrim` (discards) is now automatically enabled in LUKS2 metadata for new encrypted NFS root installations.
- This prevents potential performance issues (unresponsive systems, broken file chooser dialogs) in existing installations, requiring manual refresh (`cryptsetup --allow-discards --persistent refresh`).
- **`vers` mount option added for NFS compatibility** (EXCERPT 4):
- The `vers` option is now supported as an alias for `nfsvers` for compatibility with older systems.
- This ensures smoother mounting with NFS servers that expect the `vers` option.
- **Client-side NFS caching with FS-Cache** (EXCERPT 5):
- NFS clients can now enable FS-Cache for improved performance by reducing server load and network bandwidth usage.
- Requires a block-based cache back end (XFS, ext3, ext4) mounted under `/var/cache/fscache/` with extended attributes.
- Performance trade-off: local caching may slow down individual file operations but reduces overall server and network I/O.- **NFS with TLS support** (EXCERPT 1):
- NFS now supports fully encrypted communication using TLS for RPC traffic.
- This matters for security but may introduce performance overhead compared to unencrypted NFS.
- **`fstrim` enabled by default on LUKS2 root in ostree-based installations** (EXCERPT 2):
- `fstrim` (discards) is now automatically enabled in LUKS2 metadata for new encrypted NFS root installations.
- This prevents potential performance issues (unresponsive systems, broken file chooser dialogs) in existing installations, requiring manual refresh (`cryptsetup --allow-discards --persistent refresh`).
- **`vers` mount option added for NFS compatibility** (EXCERPT 4):
- The `vers` option is now supported as an alias for `nfsvers` for compatibility with older systems.
- This ensures smoother mounting with NFS servers that expect the `vers` option.
- **Client-side NFS caching with FS-Cache** (EXCERPT 5):
- NFS clients can now enable FS-Cache for improved performance by reducing server load and network bandwidth usage.
- Requires a block-based cache back end (XFS, ext3, ext4) mounted under `/var/cache/fscache/` with extended attributes.
- Performance trade-off: local caching may slow down individual file operations but reduces overall server and network I/O.Served via llama.cpp Metal · 27.2 tok/s · 68.8 GB RAM · coding total 90/126
No failures.
Served via llama.cpp Metal · 13.9 tok/s · 18.7 GB RAM · coding total 87/126
No failures.
Served via llama.cpp Metal · 80.5 tok/s · 18.4 GB RAM · coding total 86/126
No failures.
Served via llama.cpp Metal · 47.1 tok/s · 24.0 GB RAM · coding total 86/126
- NFS with TLS support is fully supported in RHEL 10, enabling TLS for RPC traffic to encrypt client-server communication; it depends on kernel TLS (kTLS), which is a Technology Preview. This matters because it adds a new security option for NFS deployments, though it is not yet generally available.
- The maximum `rsize` and `wsize` for NFS mounts is now 1,048,576 bytes on both client and server in RHEL 10, up from previous limits. This matters because larger transfer sizes can improve NFS performance.
- ReaR now correctly parses `nfs://` URLs containing IPv6 addresses in square brackets (e.g., `nfs://[2001:db8:ca2:6::101]/root/REAR`) for `BACKUP_URL` and `OUTPUT_URL`, fixing premature aborts. This matters for backup/restore workflows using NFS with IPv6.
- `sec=krb5p` is documented as the most secure NFS security option, providing Kerberos V5 authentication, integrity checking, and encryption, but with the most performance overhead. This matters for administrators choosing the right security/performance trade-off for NFS mounts.- NFS with TLS support is fully supported in RHEL 10, enabling TLS for RPC traffic to encrypt client-server communication; it depends on kernel TLS (kTLS), which is a Technology Preview. This matters because it adds a new security option for NFS deployments, though it is not yet generally available.
- The maximum `rsize` and `wsize` for NFS mounts is now 1,048,576 bytes on both client and server in RHEL 10, up from previous limits. This matters because larger transfer sizes can improve NFS performance.
- ReaR now correctly parses `nfs://` URLs containing IPv6 addresses in square brackets (e.g., `nfs://[2001:db8:ca2:6::101]/root/REAR`) for `BACKUP_URL` and `OUTPUT_URL`, fixing premature aborts. This matters for backup/restore workflows using NFS with IPv6.
- `sec=krb5p` is documented as the most secure NFS security option, providing Kerberos V5 authentication, integrity checking, and encryption, but with the most performance overhead. This matters for administrators choosing the right security/performance trade-off for NFS mounts.Served via llama.cpp Metal · 11.2 tok/s · 24.5 GB RAM · coding total 79/126
No failures.
Served via llama.cpp Metal · 10.8 tok/s · 37.9 GB RAM · coding total 66/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|>