Advice

[yammers]

I am currenly experimenting and bulding my own nas/media centre, I like the look of Freenas/TrueNas, however the only thing that is off putting for me is that like most nas systems, you can easily remove and add additional drives at will, and from what i have been reading about freenas/true nas, once a vdev is created you cant extend or add additional drives, you have to create a new vdev. Will this be addressed so its easier to add a new drive each time you want to increase storage or disks. is this still the same or will it be possible to just buy another disk add it to the same vdev amend the raid on it if needed and have it rebuild accross al the drives including the new one. cause at the moment OMV looks easier when it comes to adding storage

 

[artlessknave]

mirror/stripe: drives can be modified (add/remove/attach/detach) at the command line.
raidzX: add new vdevs only
truenas is generally an enterprise and enthusiast targeted nas appliance. one chooses freenas primarily for zfs and it's high data integrity (checksums of the checksums of the checksums of the data) which most other nas systems simply cannot offer (iirc OMV has a zfs plugin, but it would still be zfs with zfs limitations).
zfs is an enterprise storage solution, with enterprise costs, and absolutely no training wheels (zfs works amazing, but when it does fail it's often catastrophic - zfs assumes you have backups, and so tends to focus more on reporting errors than recovering them).
raidzX expansion is planned, but is likely at least a year away.

 

[sretalla]

once a vdev is created you cant extend or add additional drives, you have to create a new vdev.

That's a feature of ZFS, not specific to TrueNAS.

zfs assumes you have backups, and so tends to focus more on reporting errors than recovering them

Not true. Scrub (together with appropriately designed pool layout) will recover errors as is intended with ZFS (bit-rot prevention).

Backups are of course an essential part of your data protection strategy.

mirror/stripe: drives can be modified (add/remove/attach/detach) at the command line.

And in the GUI from TrueNAS 12 and up.

raidzX expansion is planned, but is likely at least a year away.

But isn't a brilliant idea in general as the data already on the disks will not gain the new striping pattern without additional effort. It just works better if you start a VDEV with the right number of disks and upgrade capacity by replacing all disks in a VDEV with larger ones.

 

[artlessknave]

Not true. Scrub (together with appropriately designed pool layout) will recover errors as is intended with ZFS (bit-rot prevention).

it was an oversimplification, but still essentially true. zfs will try to recover data but if it cannot (insufficient replicas) there are very little recovery tools - it will report anything it finds as corrupted, which can be useful, but it is, again, generally assumed you have backups in much of the core design, and so when a pool dies, they tend to really die.

But isn't a brilliant idea in general as the data already on the disks will not gain the new striping pattern without additional effort. It just works better if you start a VDEV with the right number of disks and upgrade capacity by replacing all disks in a VDEV with larger ones.

it is my understanding that part of the plan already includes that additional effort to rebuild the stripe in the background, and that developing that process is part of why it will take a long time to be realized.

And in the GUI from TrueNAS 12 and up.

oh, good, I clearly haven't tried that recently.

 

[sretalla]

it is my understanding that part of the plan already includes that additional effort to rebuild the stripe in the background, and that developing that process is part of why it will take a long time to be realized

No, that's not the case. Existing data remains at N-1 + parity while new data gets N + parity.

The time taken is based on people with sufficient time and motivation to look at the topic. It's not top of the list for Matt Ahrens (who is the one charged with it). @Yorick and I have had a look at it to attempt to move it along, which would currently represent developing the tests. We haven't managed to get it moving though due to our own time constraints.

As I was hinting at, I don't think it's an excellent idea to use it even if it does arrive, but I agree it could help some people in certain scenarios where they understand the mess they are (at least temporarily) making.

 

[artlessknave]

ah. hmm. that's...less good then, but still can be useful in the user space, as that is one of the things that drives people, like the OP here, to other projects, even though we all know that ZFS is the master race.

 

[jgreco]

as that is one of the things that drives people, like the OP here, to other projects

That's fine, no one claims that FreeNAS is the best solution for every use case. Sometimes it is merely a matter of education and experience. Early on, lots of disappointed Drobo users showed up in these forums, expecting ZFS to have magic disk addition and removal powers. They desperately wanted a NAS that actually worked, and apparently some FreeNAS converts had been talking up FreeNAS in their forums, because there were lots of mysterious problems and brokenness. Unfortunately, ZFS was really designed for an array as built, populated, sold, and shipped from a factory (Sun specifically) and doesn't have strong capabilities to remove disks or work with random drives the owner happened to have handy.

I often do not use FreeNAS, in favor of a plain vanilla FreeBSD NFS server VM, and I certainly appreciate that not every use case has to have FreeNAS as the solution.

 

[Yorick]

The tests were actually improved by someone else, I never got knowledgeable enough to be able to do that. Matt Ahrens has done additional work on it in recent months, there's some movement. You can follow along at [WIP] raidz expansion, alpha preview 1 by ahrens · Pull Request #8853 · openzfs/zfs (github.com) . It's far enough along to warrant changes to ZFS to improve its read performance, see allow callers to allocate and provide the abd_t struct by ahrens · Pull Request #11439 · openzfs/zfs (github.com)

So ... 2022? One can dream :)

 

[artlessknave]

jgreco oh absolutely but how can we be True NAS fanboys if it's not perfect? if we can't have it all why are we even here? what is the meaning of life?

 

[Yorick]

what is the meaning of life?

42, of course. D'uh.

 

[Etorix]

how can we be True NAS fanboys if it's not perfect?

By definition, fanboys voluntarily turns a blind eye to any defects of whatever they promote. Conspiracy theorists are totally oblivious to internal contradictions. And fanatics never ever engage into rational arguments.

Theory is perfect. Reality never is. TrueNAS is real.

TrueNAS is a high-quality, entreprise-grade, storage system. Accordingly, it requires advanced planning, a comprehensive backup strategy, and deep pockets to address issues where requirements change, or initial planning was sub-optimal. For a regular user, a "lesser" consumer-grade NAS system, one which allows to add drives or change layout on the fly and does not destroy all data when an unrecoverable eror occurs, may actually be a better solution.

 

[artlessknave]

fanboys voluntarily turns a blind eye to any defects

yes, that was part of the word play of the statement. fanboys are often too busy being blinded by shiny to ask for improvements. right tool for the job certainly applies...but tools can be improved.
of course, the ZFS focus on data integrity can make improvements take forever.