“Using 2 drives for multiple use cases (ARC, metadata, and SLOG) ETC

TrueNAS General
1

If this isn’t a dumb idea: I have two Intel P3700 400GB drives that I’d like to use for ARC, metadata, and SLOG all at once. I want them mirrored for the metadata so it’s redundant, but it feels like such a waste of good space if I only use them for one task. I remember it was possible to split a drive and use it for multiple vdevs, if that’s the right terminology.

I’ll also be adding five SAS SSDs for VMs and live data usage, and I plan to keep my current HDD pool as a mirrored backup via sync tasks.

If you’re wondering why I want all this speed, it’s to make testing before cloud deployment for my brother (who is a software developer) easier, as well as to host backups for his laptop. The VMs are primarily for testing.
PS: Not rich a mechanic who cosplays as a sys admin :slight_smile: cheers

2

It has never been possible to do this in any supported way. If you’re up to partitioning the drives at the shell, it’s theoretically possible, but of course issues with one of the drives affects all the vdevs you use that drive for.

1 Like
3

In that sense would one be theoretically possible to split a drive into 3 and do that to another and that make for example a mirror zdev for metadata for a pool one pool and use the second for vdevw for slog and the remainder for whater else so if one fails the other will be fine so no data loss will occur and even have a third as a spare ???

4

Theoretically possible? Sure. A good idea? No.

1 Like
5

Bad idea in the sense of too experimental and could distroy everything or too complex correct me if I’m wrong but out of the three spinal devs I want to add (slog,l2, and metadata only for the hbd pool ) the metadata is the only critical dev that would irritate if it went down and i could just have the bedbugs mirrors 3 ways two on the intel drives and a third on its own ssd or would all that overhead be defeated by the added complexity to the system

6

Bad idea on several counts:

  • Not officially supported by GUI.
  • L2ARC and SLOG may be removed to go back to a supported layout, not special vdev (if that’s what you mean by “metadata”).
  • L2ARC and SLOG are not pool critical; special vdev is.
  • L2ARC and special are partially redundant.
  • Only Optane can actually handle well doing read-intensive (L2ARC) AND write-intensive (SLOG) simultaneously; P3700 would struggle badly.
3 Likes
7

That makes a lot of sense with the ssd pool being hgst emc sas drives optain probably won’t be night and day for them it would would make sense so use on the hbd pool which wont really be used other than back up that are planned to run automatically —- did i hit nail on the head ???

So should I just make another storage pool with those intel ssd I would really hate to have them just sit collecting dust

8

You have not described your system and size requirements so it would be hard to advise.

Five is not a good number for VMs—mirrors recommended.

SSD pools need no SLOG, especially if these are data centre SSDs.
A HDD pool for backups has not much in the way of performance requirements. For ZFS replication it needs nothing. For rsync (or similar) it may benefit from a persistent L2ARC to speed up metadata reads. But we cannot discuss L2ARC without knowing about RAM and ARC performance.

Tentatively:
2*P3700 => VMs
5-wide raidz1/2 => hot data
? HDDs => cold data, backups