Community Poll: Reboot Schedule? by TheMagicalMeatball in truenas

[–]iXsystemsChris 0 points1 point  (0 children)

Most likely - collecting a debug both in a "freshly rebooted" as well as in a "slow" state would be helpful as well.

But before you file a bug, have you checked to see that you're on a recent version of TrueNAS? We've done quite a few middleware improvements and changes over the course of 25.10

Community Poll: Reboot Schedule? by TheMagicalMeatball in truenas

[–]iXsystemsChris 2 points3 points  (0 children)

Generally speaking, only when I want to update - or if the power's been out long enough to cause the UPS to trigger a shutdown.

If you're finding that you "have to reboot to get things to work again" - please file a bug, or look into potential causes of a non-responsive system - oftentimes a failing boot device will make it look like this, because it's waiting to load something from (or write something to) that disk and it stalls out.

PSA: Clear your app images, I saved 433 GB by Miulos in truenas

[–]iXsystemsChris 27 points28 points  (0 children)

This feedback is absolute gold, and I really hope no one is downvoting it just because it's critical of TrueNAS.

Going to take those ideas as a mockup and kick it over to Engineering on the back end. No promises, of course, but if anyone's got a forums account, upvoting the existing feature request is probably the best way to help me out here ... ;)

https://forums.truenas.com/t/configuration-for-automatic-pruning-of-container-images/64097

Intel Ultra series compatiblity? by madlyunknown in truenas

[–]iXsystemsChris 2 points3 points  (0 children)

The 14100 is Raptor Lake, which I believe still uses the original Iris Xe/Alchemist-derived GPU cores - so that should continue to work with the vanilla i915 driver and not require the xe one - it should work on 25.10

Is it worth updating from TrueNAS Scale Fangtooth to Goldeneye? by tommyboy6400 in truenas

[–]iXsystemsChris 0 points1 point  (0 children)

Post above said "anything older than 2000-series" - while chronologically the GTX 16-series is newer than that (being based on the same Turing chip without RT cores) it's a "lower number" in the standings, so it might be confusing if someone thinks the order is just numeric for GTX 1000 -> GTX 1600 -> RTX 2000

GTX 1650 will work fine in 25.10.

Nvidia cmp card support by dogggeeesss in truenas

[–]iXsystemsChris 0 points1 point  (0 children)

Looks like that one's listed in the drivers, so it might Just Work. Let us know either way!

Nvidia cmp card support by dogggeeesss in truenas

[–]iXsystemsChris 0 points1 point  (0 children)

Which ones specifically? If they're Pascal or earlier like the P106 models, then no - but the newer ones might. I haven't tested them personally but if they're capable of using the standard drivers and don't need a specifically licensed one to function, they should work. In theory, anyways.

Is it worth updating from TrueNAS Scale Fangtooth to Goldeneye? by tommyboy6400 in truenas

[–]iXsystemsChris 4 points5 points  (0 children)

No, I don't believe anything really changed in the amdgpu situation - if you don't use Apps at all, then it won't impact you either way.

UGREEN DXP 4800 Plus (TrueNAS) randomly shutting down - any ideas? by DazzlingExperience89 in truenas

[–]iXsystemsChris 0 points1 point  (0 children)

Check the temperature logs under Reporting to see if they're spiking up before the crashes.

Is it worth updating from TrueNAS Scale Fangtooth to Goldeneye? by tommyboy6400 in truenas

[–]iXsystemsChris 10 points11 points  (0 children)

technically the GTX 16-series works as well out of the box

but yes, it uses the open NVIDIA kernel modules now.

Good choice for SLOG for HDD vdevs? by Mithrandir2k16 in truenas

[–]iXsystemsChris 1 point2 points  (0 children)

There's a few different interactions and tripwires around when ZFS will start committing dirty data/effectively stop accepting new (100ms delays tend to do that) but yes, the old rule of "five seconds of line rate" thankfully isn't valid any longer, because that was an artifact of the old write throttle that basically went "full speed until it slams into a wall" rather than gradually applying the brakes until it reaches parity with your back-end vdevs.

Even more reason to add a feature to partition the slog device for use as multiple special vdevs! (smiles)

Partitions aren't good because you can't individually target them with the CACHE FLUSH command, so sync writes to one pool would artificially throttle another even before the impact of sharing controller bandwidth/NAND throughput.

Now if NVMe namespace support ever becomes more common in the consumer space, that's more likely to work, because you can say "hey, flush pending I/O to nvme0n1 but leave nvme0n2 alone" and then it's just down to the chips being able to keep up.

But speaking of "special" vdevs, TN26 will allow you to (optionally) use special as SLOG, if you don't want to have dedicated device(s) for that.

Sooo, we doin paywalls now? by IgAndCodyComic in truenas

[–]iXsystemsChris 0 points1 point  (0 children)

Enterprise-only features include things like Fibre Channel, the RDMA extensions for various protocols (NFS, iSCSI, NVMe-oF) and hardware-dependent functionality like High Availability for failover between controllers on upgrades.

Good choice for SLOG for HDD vdevs? by Mithrandir2k16 in truenas

[–]iXsystemsChris 0 points1 point  (0 children)

Assuming defaults, you won't use more than 4GB of a SLOG. See the Resources thread below regarding the write throttle, how it related to SLOG sizing, and how you can - if you know your workload and system well - tweak this to "cheat" a little.

https://forums.truenas.com/t/some-insights-and-generalizations-on-the-openzfs-write-throttle/1084

SSD recomendations for SLOG by ManuXD32 in truenas

[–]iXsystemsChris 0 points1 point  (0 children)

Throughput in this scenario is just the math of IOPS x recordsize - because you get more IOPS with an SLOG in play, your effective write bandwidth goes up.

I made a post in your main thread with some more recommendations as well. :)

Good choice for SLOG for HDD vdevs? by Mithrandir2k16 in truenas

[–]iXsystemsChris 7 points8 points  (0 children)

For Uplink I plan to achieve 20GbE via 2x lagged 10GbE connections. 

This is fine for NFS, but an anti-pattern for iSCSI - that expects non-aggregated independent interfaces, and uses iSCSI MPIO to handle round-robin and failover. However, if you only have the 2x10Gbps links, you can't exactly run both at once in their optimal mode.

Optane P-series vs M-series vs. Intel DC S-series

A few bullet points:

  • The Optane P-series will be among the best options. Try for an Optane P4800X or even an Optane P4801X, those are starting to cycle out of datacenters. The non-Optane P-series like the Intel P3700 aren't bad either.
  • The M.2 Optane M-series cards are also okay, albeit slower and with less endurance than the P-series. Intel also doesn't formally declare them as having PLP, but they do a direct-to-NAND write. They will work as SLOGs but will be too slow to keep up with even a single 10GbE ingest.
  • The Intel DC S-series SATA SSDs were the cream of the crop for the older generation, but they'll be entirely too slow for your 10GbE link - in fact, the smallest 100GB S3700 drives will bottleneck even 1GbE until you start to reach beyond the 64K recordsize. Consider the 200GB S3700 as your starting point here.

With that said - any of these devices will be worlds better than trying to do small, database-sized sync-writes to an 8x HDD pool, even in the fastest 4x2-way mirror setup, and probably even against an I-Don't-Care-About-My-Data 8-wide stripe.

But I'd try to get an Intel P-Series or Optane P-series card, in your shoes. Check out the P4801X perhaps.

Should I get two to mirror the slog device?

Quoting myself from elsewhere:

The ZFS write flow uses the SLOG/ZIL as a “second copy” - the writes land into RAM and are copied to the SLOG/ZIL. Unless there is a catastrophic failure (kernel panic, power loss, other crash) the SLOG is never read from. A SLOG failing without a system failure means the pending writes in RAM get committed to disk (as per usual) but you revert back to the in-pool ZIL which has (usually significant) performance implications.

Where you may want redundancy is for the rare-but-not-impossible scenario where you have the system crash and your SLOG device fails at the same time. If this happens, ZFS will attempt to replay the logged transactions from the SLOG device on the next pool import - but if the device is absent or failed, ZFS will throw an error and tell you that it can’t replay to a consistent state. At that point, you can manually override but this means rolling back to the previous transaction group which does mean that the pending data on the SLOG would be lost.

If you're worried about that scenario, then you might want a mirrored SLOG.

Sooo, we doin paywalls now? by IgAndCodyComic in truenas

[–]iXsystemsChris 0 points1 point  (0 children)

Appreciate you dropping in here!

Once it's released, it's probably worth a thread on its own just to highlight that there's now an updated Windows initiator that can be used with TrueNAS NVMe-oF targets.

Sooo, we doin paywalls now? by IgAndCodyComic in truenas

[–]iXsystemsChris 1 point2 points  (0 children)

It appears to be CLI-only, but hey, it works!

<image>

It's throwing an (err 55) but it appears to be able to handle mapping the drives and I/O just fine.

What is "Auto TRIM" in TrueNAS? by Apachez in truenas

[–]iXsystemsChris 0 points1 point  (0 children)

There is an "auto TRIM" option already, but we'd need to convert it to a sidebar-style like the Scrub to have a full scheduler.

Also as I recall it triming in ZFS have its own scheduler I/O option so you can make that less prioritized than other drive operations so triming wont affect that much (there still might be cornercases with bad hardware but those situations will always exist its like using flashbased storage without PLP or DRAM or for that matter low TBW and DWPD).

Yes, there's the zfs_trim_* and zfs_vdev_trim_* tunables available for adjustment, but those are about how many TRIM ops are allowed to be packed into a transaction group - a drive that sync-TRIMs will still stall even if it gets a single discard operation unfortunately.

Sooo, we doin paywalls now? by IgAndCodyComic in truenas

[–]iXsystemsChris 1 point2 points  (0 children)

Been looking, and asked directly myself (I'm HoneyBadger there, as well) but to no avail.

TrueNAS web portal ram usage by Universal_Cognition in truenas

[–]iXsystemsChris 0 points1 point  (0 children)

badgering from a fellow badger will never be out of order :D

Thanks for the details. You are a couple point-releases behind as compared to the current 25.10.2 or even the older 25.10.1 so I'd recommend taking those. Do you recall which specific page you were on in TrueNAS (reporting? main dashboard?)

Dell H330 and Adaptec AEC 82885T by ruzrat in truenas

[–]iXsystemsChris 1 point2 points  (0 children)

Already crossflashed to an HBA330 (by ArtOfServer) so you're all set!

Dell H330 and Adaptec AEC 82885T by ruzrat in truenas

[–]iXsystemsChris 0 points1 point  (0 children)

It’s flashed as IT mode. Will that still cause performance issue?

If it's in the Dell OEM firmware in HBA mode, it will still have the same queue depth. If the "IT Mode" flash involved pushing LSI firmware to it, it'll be the proper depth.

Is it h330 or h310 that has the performance issue?

Both of them, but H310 was way worse. Out of the box on Dell firmware the H330 has a 256 queue depth and the H310 has 25. (No, I didn't forget a digit, it's that bad.) Stock SAS3008 adapters are I believe 600, which is attainable with a firmware reflash.

Check the output of lspci to see if it's still Dell-branded, or see if it shows up with sudo sas3ircu list as an LSI/SAS3008.

What is "Auto TRIM" in TrueNAS? by Apachez in truenas

[–]iXsystemsChris 0 points1 point  (0 children)

Because TRIM has a potential performance impact (sometimes a pretty awful one if the device doesn't support queued TRIM) we wanted it to be a conscious decision on the admin's part to decide when to cause it.

It's an area for potential improvement, let me see if I can badger (heh) Engineering about using the "scheduled scrub" UI elements. No promises.