A JBOD pool possible?

[paulinventome]

So I think I know the answer but I'm fairly new so I want to confirm

Aside from a RAIDZ2 pool I am building a NVMe drive for scratch work and temp files. Now NVMe's, so long as they're working, are pretty robust, AFAIK they often have parity/raid/ecc in them. So I have a card with 4xslots and I want to build an 8TB Pool.

But performance wise, even one card is fine for my network (10gbe) so I really don't need to stripe across 4 of them, and obviously despite the fact that the NVMe are pretty robust in a stripe situation is one goes down the pool goes down.

But can I just use them as one big pool but separate drives - no stripe, no mirror, no raid? So if one does go down then only the files on that stick are lost?

Kindest
Paul

 

[Ericloewe]

AFAIK they often have parity/raid/ecc in them

So do hard disks. I'm not saying they're not more reliable - I make no comment apart from the obvious "no moving parts" and "limited write/erase cycles".

But can I just use them as one big pool but separate drives - no stripe, no mirror, no raid? So if one does go down then only the files on that stick are lost?

No. Although not strictly impossible or even that difficult to implement, it's one of those things that really adds very little value. There's really only two types of data:

1. The type that can be deleted
2. The type that must survive

That said... Pools that lose vdevs should now be importable read-only and recovering some stuff may be possible. You'd have to rebuild the whole thing to get a usable pool again, though.

 

[Etorix]

But performance wise, even one card is fine for my network (10gbe) so I really don't need to stripe across 4 of them, and obviously despite the fact that the NVMe are pretty robust in a stripe situation is one goes down the pool goes down.

You understand the situation and the answer is "NO". There's no such mode in ZFS—and no real interest for it.
But if you're confident that it's just a scratch drive, and that nothing essential would be lost in the event of a failure, there's no reason not to stripe two or more NVMe drives to just reach the capacity you need.

 

[paulinventome]

That said... Pools that lose vdevs should now be importable read-only and recovering some stuff may be possible. You'd have to rebuild the whole thing to get a usable pool again, though.

But in a case where 4x2TB are used that would have to be a stripe and I believe that would be utterly unrecoverable as the data would be across all drives?

In the case above do you mean just adding single vdevs to a pool? I am still wrapping my head around the truenas architecture but if I had an existing pool I can add a vdev but that would be added as a new dataset?

Kindest
Paul

 

[paulinventome]

You understand the situation and the answer is "NO". There's no such mode in ZFS—and no real interest for it.
But if you're confident that it's just a scratch drive, and that nothing essential would be lost in the event of a failure, there's no reason not to stripe two or more NVMe drives to just reach the capacity you need.

Thank you.

It's quite difficult to find solid data on reliance of various NVMe based drives. I've seen torture tests where the TBW way exceeds the recommended and I understand that so long as the drive is working, silicon is very unlikely to stop - but I assume there are edge cases and it can happen.

Whilst the drives wouldn't hold anything unique it would be a pain to have to rebuild the files that would be held there. It boils down to peace of mind and I supposed RaidZ1 would offer a bit of that...

thanks
Paul

 

[Ericloewe]

But in a case where 4x2TB are used that would have to be a stripe and I believe that would be utterly unrecoverable as the data would be across all drives?

Mostly, yeah. But technically any data that is exclusively on the good vdevs would be retrievable. Not fun in any way, and you're likely to end up with tons of half-broken stuff.