1. L2ARC should survive reboots
There is already an RFE for this and AFAIK it's been working on.
2. Ability to mirror ARC between cluster nodes
In some workloads it is there important to be able to sustain a provided performance. To warm up a cache it could take even hours during which time the delivered performance could be lower than usual. #1 once implemented should partly fix the issue but still filling-in 128GB of cache could take some time and negatively impact the performance. I think the replication not necessarily would have to be a synchronous one. It probably would be hard to implement and maybe is not worth it...
3. L2ARC and SLOG SSDs shouldn't be included in disk drive IOPS stats.
While I haven't looked into it very closely it seems that when graphing IOPS for disk drives both L2ARC and SLOG numbers are included in totals. I think it is slightly misleading and a separate graph should be provided just for L2ARC and SLOG.
4. Ability to create a storage pool without L2ARC and/or SLOG devices even if they are present
While this is not necessarily important for production deployments it would help with testing/benchmarking so one doesn't have to physically remove SSDs in order to be able to build a pool without them.
There is already an RFE for this and AFAIK it's been working on.
2. Ability to mirror ARC between cluster nodes
In some workloads it is there important to be able to sustain a provided performance. To warm up a cache it could take even hours during which time the delivered performance could be lower than usual. #1 once implemented should partly fix the issue but still filling-in 128GB of cache could take some time and negatively impact the performance. I think the replication not necessarily would have to be a synchronous one. It probably would be hard to implement and maybe is not worth it...
3. L2ARC and SLOG SSDs shouldn't be included in disk drive IOPS stats.
While I haven't looked into it very closely it seems that when graphing IOPS for disk drives both L2ARC and SLOG numbers are included in totals. I think it is slightly misleading and a separate graph should be provided just for L2ARC and SLOG.
4. Ability to create a storage pool without L2ARC and/or SLOG devices even if they are present
While this is not necessarily important for production deployments it would help with testing/benchmarking so one doesn't have to physically remove SSDs in order to be able to build a pool without them.
1 comment:
1. It's high on my todo list...
2. That's tough; and you are right, a persistant L2ARC can help address this problem, so long as the L2ARC devices were dual attach so that the other head node can access them.
3. Being able to easily filter on L2ARC and SLOG SSDs would be helpful, yes, which we'd like to do. Right now you need to remember which disks are which when looking at the by-disk breakdowns; although their behaviour is often a good clue.
4. In the Sun Storage 7000 series, you can deselect the L2ARC devices when creating pools, or, disable them on a share by share basis afterwards. This doesn't exist yet for SLOG devices.
Post a Comment