Allyn Malventano

This is a --bwlimit=100m transfer of several ~100GB files to another local drive. I would not expect checksum data to cause over an hour delay in the removal of the...

Additional info: - After leaving the (slow) resumed initialize going for while (>1d), I've noticed the percent complete is beginning to stratify across the drives. Pre-suspend, all drives would always...

- Here's a sampling of the % initialized before I threw in the towel on that attempt (it would have taken months to complete). Note that this spread began from...

Updated to OpenZFS 2.1.5 and increased BW to the backplanes to speed up troubleshooting. - Initialize speed: 5.5 GB/s (averaged over 1 minute) - After suspend/resume at 1%: noted high...

> -n 999999 works for me That works for me as well, but this issue is about being consistent with the command line inputs of other plotters. Also, -n 999999...

Are you guys sure you're not just seeing lower plot times for plots after the first one? I've let bladebit run for months on a system and saw zero change...

The larger issue here is that folks should not have to limit their arc/l2arc to metadata-only just as a workaround, as it trades one performance problem for another. One example...

> Sorry if I'm missing something basic here, but if you care to any significant degree about metadata performance, wouldn't you want use a special vdev for metadata and give...

With 6M files across ~1.5PiB here (384GB DRAM, 188G for ARC), I run a find every 5 minutes to try and keep metadata hot. It normally takes 20-30s, but every...

> @Ryushin @malventano Just to be sure to understand... did you set L2ARC to only cache metadata via `secondarycache=metadata`? There is no L2ARC in this system. I'm providing the data...