I haven’t heard that one before. I don’t have an answer for you but I have some questions. Is there any drive access when it’s doing that? Are you sure it’s all the drives making that noise not just one? Are they all doing that shudder at the same time? Is there any firmware updates available for the new drives? Is there a firmware update available for the controller? did you run smart tests on the drives?
Hi thanks for the reply, doing a extended smart test in TrueNAS now for all the hr disks.
The shudder is coming from all the Seagate drivers instantaneously as if they are cycling or something. Going to check if the noise stops once the system goes ideal after the smart test.
Any chance you can point me to how I could check regarding a firmware upgrade, I assume I would need to pull each drive and upgrade, or could I do this within TrueNAS.
Can’t say I have ever heard that before. Sounds scratchy, is that coming from the drives or something else? The shuddering is normalish but it sounds a bit off. I would do a long smart test to get a better answer if you are unsure. Ideally you should stress test all new drives.
The answer to this is a little more dependent on what you have running on your primary. If it’s solely a file share, then yes. Rsync can be used to simply mirror your pool from one host to another, effectively making a mirror copy.
If you are running applications like jails, plugins, etc, then this answer can sometimes become more complex. Sometimes those applications, jails, whatever only need to have their files copied, which might mean you have to create the application on your backup and then restore the files.
Certain applications that are more complex are affected by a concept called crash consistency. If something uses a database or vm that’s reading and writing, when you copy the database it may not be consistent meaning there are things in the middle of being read and written. And that case you needed to have the application stop finish all of its operations and then copy the files. This is likely more complex for may not be applicable to your situation.
If you want to ask specific questions about restoring applications, jails, VMS on trunaz, I would suggest hitting up the trunez community forum after you read the manual a couple of times, they’ll eat your lunch if you ask a question that could be simply answered by reading the manual
Specially if you are considering leaving it as storage only, I’d say it’s totally worth it sticking to CORE.
It’s stable, tried and tested. And it works. Even if fancy new features like RAIDZ Expansion won’t make it to the GUI, it’ll probably work just fine from CLI.
I have a CORE box as my NAS / Home Server with many Jails running my stuff in it and I don’t plan to switch from that anytime soon. Maybe if my services stop supporting FreeBSD, then I’d start by migrating them to Docker containers running in a Linux VM, and when all of them are migrated, then I’d consider going the SCALE route.
Just got a system up and running. Silverstone cs382 chassis with 6 12tb drives. 4 are in a striped mirror set and the other two are mirrored. I wanted protection and speed. The os and docker apps each have their own 1tb SSD. Rest of the hardware is old from eBay.
I’m coming from open media vault so although I’m not running anything but rsync now, I will be setting up a wordle clone, an intranet, and backup for family photos. I run some of the same stuff as you but I’ll have to look up what the rest are. Tailscale is something I’ve wanted to do but haven’t dug into it yet.
I may set up a task list for the kids chores as well.
Plex and all the associated things.
Not sure what else yet as I’m still setting up replication and stuff to protect what I have first.
No, not really. You’re going to want to read the TrueNas forum primers for ZFS and vdevs if you haven’t already. It’s critically important.
The data parity, error correction, and rebuild is within the zdev. If you lose a drive in the mirror, it’s rebuilt from the other drive in the mirror.
If you lost a disk in a z1 vdevs, it’s rebuilt from the other drives in the set.
A key concept of there is no parity and error correction during the period of a loss of a drive in a mirror or z1 until the resolver is complete. That’s why there’s z2/3/… Or you can create mirrors with more than two disks. Obviously some trades on capacity.
The rebuild speed is more about the drive size. Spinning drives can only write so fast, doesn’t matter how many other disks in the vdev. 4TB is long time, 12TB+ is eternity. SSD, much faster.
I wasn’t completely clear I think. I currently have 1*mirror vdev of 8TB each disk. I’m thinking of adding another mirror vdev of the same capacity. That would stripe the data between both. Meaning that per vdev there would be less data. That would lead to quicker (thus safer?) resilversing in the case of a singular disk failure per vdev, correct?
If you have two 8TB drives in mirror, oddly, ZFS doesn’t move the existing data when you add a second vdev of two drives. All newly written data will be stripped across both sets. If you want your existing data stripped, you have to move it back on.
As for rebuild(resilver), the data on the other device in the vdev and CPU power rebuilds the missing data.
If you have less data on each vdev, then only then could you consider it faster than if the vdev had more data on it. You are basically making the point that restoring less data is faster than more data.
People usually end up with more data as they expand a pool. This makes rebuild slower.
If you plan on lots of data, or want more protection, use z2. If you need performance like hosting VMs or databases, then use mirrors.
I think for now that should be fine. I got daily cloud backups, and got a way to remotely turn off the PC if a disk degrades or faults. I might also even get a disk as hot or cold spare just to be sure. With 2 mirrors I got quite a bit of performance, and in a sense better off than with a single mirror.
I’m using the storage to host Nextcloud, and the performance was just not really good enough with a singular disk of speed. I’m hosting it for me and the wife so we can both share pictures with each other without needing a privacy invasive third party :)
I’m not sure exactly what your setup is, if you have data in the OS pool that might be gone, unless you can boot the system from a stick and mount that disk to copy data over. Zpool export isn’t strictly necessary.
If your data is in a different pool then it should be theoretically easy to just import that pool in a new install.
This is good to know. I have my OS on nvram and my data pool on a disk array. If u lose a disk on the pool, zfs should take care of that. If I lose the os disk or is gets corrupt, then based on what u say above, it should be easy enough to reinstall Truenas scale on new nvram, import the pool and then import the last config file to setup all the shares which otherwise would have to be setup manually from scratch. Does that sound right?
I’ll be honest, I never tried it that way. But it should be possible. If you have the possibility, I’d advise to simulate that in a VM, then you’ll know for sure! But basically importing zpools should even be OS agnostic, as it is an open standard that you can just install on any OS. I’ve heard stories about people even migrating pools from core to scale and vice versa, which is going from BSD (core) to scale (debian linux).
Thanks for the clue. I haven’t been able to find anything in my config. Is there supposed to be a text field for setting auxiliary parameters, or are we just referring to advanced options here? Do they need to be configured via the shell in Scale? I’ve included screenshots of my SMB/share config below.
Next step will be to just install Scale fresh and re-config from scratch, importing the existing pool. This will hopefully eliminate any odd parameters that shouldn’t have been carried over from BSD.
Also, and I’m just venting now, why isn’t any of this mentioned in the Truenas article for the migration, or the supplemental “Preparing to Migrate…” article…?
According to this, that is about as hot as the temperatures that existed during the Hadron epoch, or the time period when the universe was between 20 microseconds and 1 second old.
In physical cosmology, the hadron epoch started 20 microseconds after the Big Bang.[1] The temperature of the universe had fallen sufficiently to allow the quarks from the preceding quark epoch to bind together into hadrons. Initially, the temperature was high enough to allow the formation of hadron/anti-hadron pairs, which kept matter and anti-matter in thermal equilibrium. Following the annihilation of matter and antimatter, a nano-asymmetry of matter remains to the present day. Most of the hadrons and anti-hadrons were eliminated in annihilation reactions, leaving a small residue of hadrons. Upon elimination of anti-hadrons, the Universe was dominated by photons, neutrinos and electron-positron pairs.
I don’t want to start making assertions without knowing the specific manufacturer and model of the drive involved, but given that hard drives generally rely upon the existence of electrons to function, which don’t exist at that temperature, one might want to keep an eye out for any other potential signs of trouble showing up, like slower access times or unusual noises.
Somewhere between “melting point of steel” and “core of the sun”. Granted this is a very wide window but your average disk temp is orders of magnitude higher.
truenas
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.