Determine alignment and remedy

[Slippery]

Hello World! I'm seeing very poor r/w performance on my FreeNAS setup, and I suspect the disk sectors are missaligned. But my duckduck-fu betrays me, so I cannot find a way to determine if this is the case or not. How can I know for sure?

Setup:
FreeNAS-11.2-RELEASE-U1
5x 4TB Seagate Baracuda ST4000DM004-2CV104
16GB RAM
AMD FX-8300 8-Core CPU

 

[HoneyBadger]

ST4000DM004

Far more likely this is the cause as these are SMR drives - I assume these are in a RAIDZ1 based on the drive count (5) as well which will impact random access speeds. What type of data are you serving from this pool (SMB, NFS, iSCSI) and to how many clients?

But to check your alignment (ashift in ZFS speak) run this command from a shell/SSH session:

zdb -U /data/zfs/zpool.cache | grep ashift

You should only have results showing ashift: 12

 

[Slippery]

I’ve got ashift: 12... so I guess that partitions are aligned... Client wise it’s a home server, so like 3 via nfs, 1 via smb. But the performance gap is local on the machine itself. What about SMR?

 

[HoneyBadger]

NFS often generates sync writes, which can lower performance without a high performance SLOG device; but my thoughts are more with the SMR drives.

SMR stands for Shingled Magnetic Recording; the short version of "why this is bad" is because "writes can often overlap previous sectors" and you have to re-order them. Picture a deck of playing cards, and being asked to put a new card into position 10 - but you can't fan the cards out, and instead have to flip over the first 9, put the new card in place, and then replace them.

 

[Slippery]

Thanks for that knowledge sharing! I'll read up more on SMR. Would a SLOG device help at all?

I made these while investigating, dropping them here for record keeping. :)
gpart: https://pastebin.com/ZrxVP6ge
diskinfo: https://pastebin.com/S5KKAzQN
geom: https://pastebin.com/gEfM3Wh2

 

[HoneyBadger]

SLOG would help if the only issue is the NFS sync writes being slow - it wouldn't help with async writes, or reads.

Open a shell window (directly via SSH, not the webUI - it's better that way) and run gstat -dp and see if you have particularly high values for the milliseconds per read/write/delete column. It can't show "internal operations" such as the disk reshingling itself, but if you try to add additional operations while the drive is doing its own internal housekeeping then they'll probably come back very slowly.