Can't fork so uploading here a port of the script

[paulstejskal]

Invoke-WarmPerformanceTier.txt

I ported via Claude Sonnet and tested and it worked in the lab. Perhaps we can merge this?

[kcantrel]

Thanks for your contribution. However, in my test, with a volume that had a 10 and 20GB file, it threw an error. Here is the error:

Errors:
  \\10.100.13.45\test_tiering\bigfile10g: Cannot convert argument "val2", with value: "2147483648", for "Min" to type "System.Int32": "Cannot convert value "2147483648" to type "System.Int32". Error: "Value was either too large or too small for an Int32.""
  \\10.100.13.45\test_tiering\bigfile20g: Cannot convert argument "val2", with value: "2147483648", for "Min" to type "System.Int32": "Cannot convert value "2147483648" to type "System.Int32". Error: "Value was either too large or too small for an Int32.""

[paulstejskal]

Here's Claude's response:
Found the bug — thanks for the repro, Ken.

Root cause: line 89 in Invoke-WarmPerformanceTier.ps1:

$blockSize = $BlockSizeMB * 1MB

1MB is a System.Int32 literal, and with the default -BlockSizeMB 2 the product (2097152) still fits in Int32, so PowerShell keeps $blockSize typed as Int32 rather than promoting it to Int64.

Later, at line 122:

$toRead = [Math]::Min($blockSize, $length - $offset)

$length - $offset is Int64 (file length can exceed 2GB), but $blockSize is Int32. PowerShell's overload resolution picks Math.Min(Int32, Int32) and tries to coerce the Int64 value down to Int32, which throws for any value >= 2,147,483,648 (2^31) — i.e. any file over 2GB. That's also why both your 10GB and 20GB files show the identical error value 2147483648: with 2MB blocks (2^21 bytes), the "remaining bytes" counter passes through exactly 2^31 for both files regardless of overall size.

Fix (one line, copy/paste):

- $blockSize = $BlockSizeMB * 1MB
+ $blockSize = [int64]$BlockSizeMB * 1MB

Casting to Int64 keeps the multiplication result Int64, so Math.Min resolves to the (Int64, Int64) overload and no coercion is needed.

Verified locally: reproduced your exact error against a real 10GB sparse file with the original code, then confirmed all 5120 blocks read cleanly with the fix applied.

Hopefully that works for you Ken. If not, please hmu on Teams.