median sparrow
Does anyone know if optimized volume move will be disabled when moving a volume (within the cluster) from an A400 to a C30? Because of the QAT (re-)compression maybe?
We have a system that seems to copy the data back from S3, even though it should use optimized volume move (i.e. same S3 bucket for all aggregates, same object store config, etc.)
If so, is that documented somewhere?
minor mist
I also don't find it documented anywhere. AFF-nodes with QAT would usually recompress the data during (after?) vol move when coming from non-QAT nodes.
https://kb.netapp.com/on-prem/ontap/DP/SnapMirror/SnapMirror-KBs/How_do_platforms_supporting_QAT_or_zlib_compression_impact_SnapMirror_and_volume_move%3F
But unsure if it would ignore the tiered blocks and recompress everything.
But I think the A400 was the only platform which used another compression algo leveraging that 100Gb hardware-offload card from Pensando. Maybe there's some incompatibility using this algo with newer nodes, so it might actually need to recompress all blocks even the tiered ones.
the X1151A card in slot 3 with the 2x RJ-45 ports
willow creek
Good question. I wonder if you can check the event logs for this?
https://kb.netapp.com/on-prem/ontap/Ontap_OS/OS-KBs/How_to_determine_if_a_volume_move_is_optimized
When you say the vol move "seems to copy the data back from S3", do you mean the data get re-hydrated to the performance tier of the vol move destination?
Or does it get copied from S3 and then is immediately tiered back to S3 from the dest volume perspective during the vol move?
My understanding from reviewing some docs is when doing a vol move from QAT to non-QAT is the behavior should be the latter. That is, data is read back from S3 and decompressed then immediately placed in the tlog for tiering and re-compression. So, we don't do an optimized vol move in these cases.
median sparrow
yeah, we looked at the event logs but found neither of the two messages. When looking at the encryption we noticed that it has changed from lzopro to zlib, so that's also our current working theory that the vol move pulls all data back and re-compresses it
willow creek
Well at least that matches our internal docs :). I imagine while we might consider that non-optimized, maybe Engg. doesn't exactly, so we don't log. In any case, I'm going to update that first KB that OG1 mentioned with the fabricpool cases.
median sparrow
I mean we're lucky that this FP is local and not in AWS or somewhere else with excessive egress costs