winnielinnie
MVP
- Joined
- Oct 22, 2019
- Messages
- 3,641
* I've read through the entire FreeNAS 11.2 U6 guide. I've read some materials that were highly recommended on these forums. I've read through some FreeBSD documentation.
More familiar with using Linux (LVM, dm-crypt/LUKS, mdadm), I'm still having difficulty understanding how redundancy and encryption works on a FreeBSD system / FreeNAS appliance.
-----
Confused: Zpool commands automatically understand vdevs and underlying physical disks? Zpool commands don't simply see vdevs, but actual physical disks underneath?
The mantra used is "Disks make up vdevs. Vdevs make up zpools." Such that you can supposedly increase the size of your zpool by slapping together a bunch of mirrored vdevs.
Makes sense, so far, so good.
You start off with a zpool named data-dump-pool, which consists of a single vdev named mirror-1, which consists of two physical disks that are 10TB each.
Total capacity of your zpool so far: 10TB
You wish to increase the zpool (data-dump-pool) by 5TB, so you purchase two additional physical disks that are 5TB each. You create a vdev named mirror-2 which consists of these two new 5TB disks, and you add the vdev (mirror-2) to your zpool (data-dump-pool). Now data-dump-pool is comprised of mirror-1 + mirror-2.
Now your zpool (data-dump-pool) increases in total capacity from 10TB to 15TB, consisting of two mirrored vdevs mirror-1 + mirror-2 (10TB + 5TB), with each vdev being a simple mirror of two disks.
As far as I can grasp from using the FreeNAS web interface, when you attempt to "extend" a zpool, you are selecting physical disks to combine into a vdev to "add" to the existing zpool's capacity. However, when reading through the underlying commands (such as recover from a single disk failure, or offline a disk, or replace a disk), you are issuing zpool commands. (E.g., zpool offline data-dump-pool /dev/gptid/xxxx-xxxx-123456). Is it that the zpool command automatically knows which particular vdev you are working with simply by the disk/partition/gptid name given? I intuitively understand "offlining" a disk in a software RAID, such as with mdadm in Linux, yet in the case of ZFS, the previous example is akin to offlining a physical disk via Linux's LVM comprised of mdadm software RAIDs (which wouldn't make sense in that ecosystem.)
-----
Confused: I've read that you cannot add more disks to a vdev once it is created (with the exception of going from a single disk, to a mirrored vdev).
I can understand this limitation for Raid-Z, but what about simple mirrored vdevs? Is it true you cannot add a third physical disk to a mirrored vdev once it is already created? If I have a 10TB mirrored vdev of two physical disks (10TB + 10TB), why can't I add in the future a third 10TB disk to this mirrored vdev (10TB + 10TB + 10TB) to mitigate against failure? I thought mirrored vdevs were the simplest form of redundancy with no limitations to removing and adding more physical disks. They may be the least efficient in terms of usable capacity, but they are the easiest to work with.
-----
Confused: In Linux, with dm-crypt / LUKS, only one "block device" is encrypted, regardless of how many physical disks comprise the software RAID or volume group. In FreeBSD / FreeNAS, it appears that encryption/decryption is done on each individual disk?
If this is the case, does that mean a FreeBSD / FreeNAS system, with an encrypted zpool that is comprised of vdevs of many physical disks, has to run a decryption process for every single disk that exists? If the zpool consists of 8 disks, then your CPU is running 8 different decryption processes each time data is being read from the zpool?
In Linux, using dm-crypt / LUKS, there is only a single container to encrypt/decrypt the data. You could slap together 8 physical disks in whatever redundancy you choose, and yet this entire block device (of all your disks) is encrypted. Each individual disk is not encrypted: the entire block device is. Your CPU does not need to run decryption for 8 physical disks: it only has to run a single decryption process for the entire block device / volume. Is there an equivalent method for this using FreeBSD / geli?
More familiar with using Linux (LVM, dm-crypt/LUKS, mdadm), I'm still having difficulty understanding how redundancy and encryption works on a FreeBSD system / FreeNAS appliance.
-----
Confused: Zpool commands automatically understand vdevs and underlying physical disks? Zpool commands don't simply see vdevs, but actual physical disks underneath?
The mantra used is "Disks make up vdevs. Vdevs make up zpools." Such that you can supposedly increase the size of your zpool by slapping together a bunch of mirrored vdevs.
Makes sense, so far, so good.
You start off with a zpool named data-dump-pool, which consists of a single vdev named mirror-1, which consists of two physical disks that are 10TB each.
Total capacity of your zpool so far: 10TB
You wish to increase the zpool (data-dump-pool) by 5TB, so you purchase two additional physical disks that are 5TB each. You create a vdev named mirror-2 which consists of these two new 5TB disks, and you add the vdev (mirror-2) to your zpool (data-dump-pool). Now data-dump-pool is comprised of mirror-1 + mirror-2.
Now your zpool (data-dump-pool) increases in total capacity from 10TB to 15TB, consisting of two mirrored vdevs mirror-1 + mirror-2 (10TB + 5TB), with each vdev being a simple mirror of two disks.
As far as I can grasp from using the FreeNAS web interface, when you attempt to "extend" a zpool, you are selecting physical disks to combine into a vdev to "add" to the existing zpool's capacity. However, when reading through the underlying commands (such as recover from a single disk failure, or offline a disk, or replace a disk), you are issuing zpool commands. (E.g., zpool offline data-dump-pool /dev/gptid/xxxx-xxxx-123456). Is it that the zpool command automatically knows which particular vdev you are working with simply by the disk/partition/gptid name given? I intuitively understand "offlining" a disk in a software RAID, such as with mdadm in Linux, yet in the case of ZFS, the previous example is akin to offlining a physical disk via Linux's LVM comprised of mdadm software RAIDs (which wouldn't make sense in that ecosystem.)
-----
Confused: I've read that you cannot add more disks to a vdev once it is created (with the exception of going from a single disk, to a mirrored vdev).
I can understand this limitation for Raid-Z, but what about simple mirrored vdevs? Is it true you cannot add a third physical disk to a mirrored vdev once it is already created? If I have a 10TB mirrored vdev of two physical disks (10TB + 10TB), why can't I add in the future a third 10TB disk to this mirrored vdev (10TB + 10TB + 10TB) to mitigate against failure? I thought mirrored vdevs were the simplest form of redundancy with no limitations to removing and adding more physical disks. They may be the least efficient in terms of usable capacity, but they are the easiest to work with.
-----
Confused: In Linux, with dm-crypt / LUKS, only one "block device" is encrypted, regardless of how many physical disks comprise the software RAID or volume group. In FreeBSD / FreeNAS, it appears that encryption/decryption is done on each individual disk?
If this is the case, does that mean a FreeBSD / FreeNAS system, with an encrypted zpool that is comprised of vdevs of many physical disks, has to run a decryption process for every single disk that exists? If the zpool consists of 8 disks, then your CPU is running 8 different decryption processes each time data is being read from the zpool?
In Linux, using dm-crypt / LUKS, there is only a single container to encrypt/decrypt the data. You could slap together 8 physical disks in whatever redundancy you choose, and yet this entire block device (of all your disks) is encrypted. Each individual disk is not encrypted: the entire block device is. Your CPU does not need to run decryption for 8 physical disks: it only has to run a single decryption process for the entire block device / volume. Is there an equivalent method for this using FreeBSD / geli?
