-M exec and the
smartd-runner which is apparently a Debian specialty.
Package Maintainers and system administrators can put scripts to be run
when smartd detects an error into /etc/smartmontools/run.d. These
scripts will be run by smartd-runner using run-parts(8). The script will
receive the filename of the file containing the errormessage as first
parameter. See /etc/smartmontools/run.d/10mail for an example.
The main purpose of this runner seems to be making sending mail optional (depending on whether a mailer is installed in the first place) and separately, it seems to trigger a pop-up notification on a desktop (if the desktop notifier is installed).
So I guess you could modify that 10mail script to filter out duplicate mails.
The alternative would be running smartd with the
--savestates option, and then use
-M once in the smartd.conf - this is described in more detail in the smartd.conf manpage, to summarize:
once - send only one warning email for each type of disk problem
daily - send additional warning reminder emails, once per day,
diminishing - send additional warning reminder emails, after a
one-day interval, then a two-day interval, then a four-day
test - send a single test email immediately upon smartd startup.
exec PATH - run the executable PATH instead of the default mail
And if that doesn't work, you'll either have to - live with it, or write your own mail handler exec logic that filters accordingly after all.
I am fully aware of the dangers implied with a disk with uncorrectable sector(s). (This disk is used in a RAID10 configuration)
I still recommend replacing such drives immediately. Whatever promises RAID makes regarding redundancy is only valid as long as each drive is in 100% working order.
Once the drive is replaced you can do a full write test on the removed drive without risking data loss - and depending how the drive fares in this test you can make a much more informed decision whether to keep using that drive (preferably outside of raid) or not.
You don't know how broken your drive really is until you put it to the test - and your smartd.conf doesn't look like you're running regular self-tests, so errors may stay undetected for a long time. And this is how RAIDs die during rebuild.