- Joined
- Jan 1, 2016
- Messages
- 9,703
Hi All, I'm posting this knowing I'll get a bit of response in confused anger that FreeNAS clearly doesn't do this now... I know that.
I'm curious if it has been something on a request list or if it is something available in TrueOS (and reserved for that platform only, I presume if that's the case).
I can see the great potential for benefit in many of the cases where we see complaints about performance related to the "right" balance between redundancy and storage capacity versus performance, particularly for VMs, but more generally .
So how would I see this working in order to add the benefit I'm talking about without the risk?
Let's say we want a high-performing pool with good redundancy, but not so much we need to go to the usual stripe of 3-way mirrors to allow for 2 device failure within a VDEV...
So what I would see is a pool that is able to manage 2 RAIDZ2 VDEVs, 1 of "high speed" and another of "large capacity" drives.
So for example:
The logic behind this would then do all writes on the HighSpeed VDEV, meaning fast writes and possibly no need for SLOG.
The logic would then manage all reads as usual from the pool, taking data from where it lies.
Some process would then run either in the background, scheduled or in real-time to move data from the HighSpeed VDEV to the HighCapacity VDEV in order to maintain a good (but perhaps configurable) amount of free space on the HighSpeed VDEV.
In addition, there would be some kind of evaluation done (similar to and perhaps in conjunction with ARC) which then decides to move data in either direction as it is accessed more or less frequently (after being in an ARC hit, the file should be on the HighSpeed VDEV until needs to be moved to accommodate space to meet either the previous point or to free space for a more recent hit from the HighCapacity VDEV. (I guess ARC and L2ARC already have this logic covered somehow, but perhaps at block level, so this would just translate a file with a hit on one block to moving the entire file).
I suppose we could consider marking VDEVs as HighSpeed or HighCapacity and allowing more than 2 in a pool and just apply the rules above in the same way, not being concerned about which VDEV amongst the HighSpeed ones or the HighCapacity ones gets the file in each case.
I would also suggest that an additional "bonus credit" option would be to allow a third or even more layers of tiering like this:
Where VeryHighCapacity VDEV disks are archive HDDs with slow/reduced read performance.
What do people think... would this make FreeNAS "THE" option for iSCSI/virtual storage that performs like a rocket at a reasonable price without compromising redundancy?
I think what I'm describing here is in some way like Apple's CoreStorage option known as FusionDrive, but obviously would be much better since it's ZFS and FreeNAS.
I'm curious if it has been something on a request list or if it is something available in TrueOS (and reserved for that platform only, I presume if that's the case).
I can see the great potential for benefit in many of the cases where we see complaints about performance related to the "right" balance between redundancy and storage capacity versus performance, particularly for VMs, but more generally .
So how would I see this working in order to add the benefit I'm talking about without the risk?
Let's say we want a high-performing pool with good redundancy, but not so much we need to go to the usual stripe of 3-way mirrors to allow for 2 device failure within a VDEV...
So what I would see is a pool that is able to manage 2 RAIDZ2 VDEVs, 1 of "high speed" and another of "large capacity" drives.
So for example:
Code:
pool1
RAIDZ21-HighSpeed
da0 (512GB SSD)
da1 (512GB SSD)
da2 (512GB SSD)
da3 (512GB SSD)
RAIDZ22-HighCapacity
da4 (8TB HDD)
da5 (8TB HDD)
da6 (8TB HDD)
da7 (8TB HDD)
The logic behind this would then do all writes on the HighSpeed VDEV, meaning fast writes and possibly no need for SLOG.
The logic would then manage all reads as usual from the pool, taking data from where it lies.
Some process would then run either in the background, scheduled or in real-time to move data from the HighSpeed VDEV to the HighCapacity VDEV in order to maintain a good (but perhaps configurable) amount of free space on the HighSpeed VDEV.
In addition, there would be some kind of evaluation done (similar to and perhaps in conjunction with ARC) which then decides to move data in either direction as it is accessed more or less frequently (after being in an ARC hit, the file should be on the HighSpeed VDEV until needs to be moved to accommodate space to meet either the previous point or to free space for a more recent hit from the HighCapacity VDEV. (I guess ARC and L2ARC already have this logic covered somehow, but perhaps at block level, so this would just translate a file with a hit on one block to moving the entire file).
I suppose we could consider marking VDEVs as HighSpeed or HighCapacity and allowing more than 2 in a pool and just apply the rules above in the same way, not being concerned about which VDEV amongst the HighSpeed ones or the HighCapacity ones gets the file in each case.
I would also suggest that an additional "bonus credit" option would be to allow a third or even more layers of tiering like this:
Code:
pool1
RAIDZ21-HighSpeed
da0 (512GB SSD)
da1 (512GB SSD)
da2 (512GB SSD)
da3 (512GB SSD)
RAIDZ22-HighCapacity
da4 (8TB HDD)
da5 (8TB HDD)
da6 (8TB HDD)
da7 (8TB HDD)
RAIDZ22-VeryHighCapacity
da8 (14TB HDD)
da9 (14TB HDD)
da10 (14TB HDD)
da11 (14TB HDD)
Where VeryHighCapacity VDEV disks are archive HDDs with slow/reduced read performance.
What do people think... would this make FreeNAS "THE" option for iSCSI/virtual storage that performs like a rocket at a reasonable price without compromising redundancy?
I think what I'm describing here is in some way like Apple's CoreStorage option known as FusionDrive, but obviously would be much better since it's ZFS and FreeNAS.
