XigmaNAS

Hello. I decided to try out Freenas (sorry!) to see what it was like. I imported a ZFS pool that I made in N4F, but once I started reading that Freenas doesn't play nicely with ZFS pools that weren't created through its own GUI, I decided to give it up.

I booted up to N4F and although the ZFS pool and datasets come up in the manager in the WebGUI, the mount point seems to have been changed. It was mounted in the root directory and I tried to change it back to /mnt/Pool (just by doing zfs set mountpoint=...) but that didn't do much. Did Freenas mess up my ZFS badly? I can post logs just tell me which ones and where they are located. The weird thing is, I booted to Freenas before this once and it didn't affect anything. All I did was "import ZFS pool" in Freenas and then try to add the path. Didn't upgrade the ZFS pool or anything.

Also, I used Raidz1 - is this still ok with drives bigger than 2 TB? I see people talking about how it is likely for there to be a read error when rebuilding a failed drive, but I'm still unsure about the legitimacy of the claim. Thanks.

Emeds wrote:It was mounted in the root directory and I tried to change it back to /mnt/Pool (just by doing zfs set mountpoint=...) but that didn't do much.

Did you verify that the mountpoint got changed by running zfs get mountpoint afterwords? If it's correct, try rebooting? Also check if the datasets have their mountpoints inherited from pool or not.

Emeds wrote:Also, I used Raidz1 - is this still ok with drives bigger than 2 TB? I see people talking about how it is likely for there to be a read error when rebuilding a failed drive, but I'm still unsure about the legitimacy of the claim. Thanks.

There are two points to consider here: how likely you are hit by an unrecoverable read error while rebuilding the array, and how likely another drive just goes and dies on you while you're rebuilding the array.

Consumer drives are only rated for an "unrecoverable bit error (UBE) rate" of less than one bit in 10^14 bits read. 10^14 bits is just 12.5 TB. So if you have a full 6 TB drive, it sounds like you'd get an unrecoverable bit error if you read it three-four times.

However, there is an important point to note. The wording of the definition says the rate is less than one bit in 10^14. That means the rate is 1/10^14 = 10^-14, and that this rate is an upper bound. In practice it seems most disks today have a much, much better UBE rates.

For example, I had an array of 6x WD Red 3TB, which was filled to ~75% for over a year, and the whole array was two years old. I did weekly scrubs. That means I know the drives read over 100 TB, yet I checked all the scrub results and not a single one reported any errors. I say "had" there because I recently rebuilt the array, adding two more 3TB disks.

Also, from what I understand, if ZFS experiences a read error during rebuild, it will just fail to recover the file it was working on, not the whole array.


Now, the other failure mode is that the disk just dies on you. More often than not in my experience, it's actually some electronics or mechanical issues with the drives that fails first. This means the controller board dies, or something mechanically fails. If you have disks of the same make and model, and manufactured close in time, then the components that causes the failure can fail in several disks at nearly the same time. The extra stress of the rebuild process can "push" one of the other drives into failure.

That's why you see people recommending you don't buy all your disks in one go, so you try to avoid the same production dates.

In my experience, this is the more likely failure mode. The failure mode is not related to disk size directly, however larger disks means longer time to rebuild the array, meaning you're vulnerable for longer. For example, my current array with 8x WD Red 3TB in two RaidZ-1 vdev's (4 disks each) currently takes 13 hours to rebuild. If my array had been with 6 TB drives, and I had filled that up to the same % level, it would take 26 hours.

Alright, great, thanks for the reply! I restarted and then my pool was properly mounted in /mnt but the datasets weren't showing up so I went to zfs set mountpoint= for the datasets, but I got "error, device busy" so I just added the -f flag to force it. Now all the files display correctly!

About drives failing - so I think it's safe to say it *probably* won't happen. which is good enough for my case.