If you rsync from an SMR drive, make sure that filesystem is mounted read-only or with noatime option.
Otherwise the SMR drive will need to write a timestamp for each file rsync reads, resulting in a significant performance degradation (from around 80 mb/s down to 3-5 mb/s here) and head wear / clicking noise.
If you already have an rsync job running with poor performance, there is no need to stop it, you can remount the source filesystem doing
sudo mount -o remount,ro /path/to/source/fs
The effect will not be seen immediately, be patient and wait 10 to 20 minutes, until the drive has finished to write out all the data still in its buffers. This advise is tried and tested ok.
This might also apply when rsyncing to an SMR drive, i.e. if the filesystem tries to update the timestamp after the file has been fully written to disk. This jitters sequential workload and huge bands of data are continuously rewritten, contributing to drive wear. The following may help:
sudo mount -t fs_type -o rw,noatime device /path/to/dest/fs
This has to be done, before rsync is run; other factors may render this option insignificant, i.e. unbuffered FAT/MFT updating, parallelized writes if the filesystem is optimized primarily for SSDs, etc.
Try to use dd bs=32M and then resize the filesystem on the SMR target, if you want to backup full filesystems anyway (no need to have it mounted and run rsync to transport each and every file in this case).
Exemplary hardware in use here was a Seagate drive managed SMR 8tb consumer drive. Your mileage may vary with other hardware.
Are you the same user as “Read only” over at this question?
– JakeGould – 2018-01-28T05:13:57.187