[mythtv-users] Shingled (SMR) hard drives

Stephen Worthington stephen_agent at jsw.gen.nz
Fri Feb 4 04:44:25 UTC 2022


On Thu, 3 Feb 2022 11:11:26 -0500, you wrote:

>Given that recordings are using large files accessed sequentially, is the
>potential slowness of a shingled hard drive a real problem for a backend?
>Anyone have first hand experience?
>
>Looking to add storage volume via an upgrade.

Never use shingled drives for recording or anything else that may be
affected by a write taking up to a minute or two when it has to
rewrite shingled tracks.  Yes, recordings are written sequentially,
BUT:

- MythTV can write more than one recording at once to a recording
drive.

- When writing any file on a drive, every time it needs to be created,
or extended to add more space, the filesystem needs to update the
directory entries for that file with the new size information.

So even when just writing one sequential recording to disk, writes
will be needed to at least one other disk location (for directory
data) from time to time, and when the file is initially created.
MythTV has RAM buffering for only a very short amount of each
recording - a few seconds.  If the data can not be written to disk
before the RAM buffer overflows, it will be lost, causing corruption
of the recording.  If a shingle rewrite of the directory data is
required when the recording file is opened, you will lose data at the
start of the recording.  That is not too bad, but annoying.  If it
happens at any other time, you get a corrupt recording.

With writing to an SMR drive, when it is initially empty, there is no
shingled data to be rewritten, so you can see good performance for a
long time, except for directory writes.  But when the drive is getting
fuller, and more shingle rewrites happen, the performance gets very
bad every time a shingle rewrite happens.  It depends on the drive,
but the typical worst case shingle rewrite times can be as much as a
minute.  They are almost never shorter than the amount of buffering
mythbackend provides for recordings.  Read performance is also bad
during a shingle rewrite - the heads can not be moved during the
shingle rewrite process so only data already under the heads or in the
drive's RAM buffers can be read quickly.

If you want to use SMR drives with MythTV, you can do what I do and
use them for storing old recordings, by moving the old recordings to
the SMR drives, freeing up space on the recording drives.  I have 6
"archive" drives now that work that way, and four of them are shingled
(Seagate ST8000AS0002 archive drives, 8 Tbytes).  The archive drives
have their recording partitions on a separate "Archives" storage
group, which is never set in any recording rule as a storage group to
record to.  The normal recording drives (7) are in the "Default"
storage group, which is the default location for an new recording
rules to record to.  All my archive drives are mounted on two USB 3.0
multidrive mounts (x4 and x2).  This allows me to unmount them and
turn them off when I do not need them - which saves a decent amount of
electricity (6 drives x average of say 5 watts per drive = 40 watts).
I have written myself software to manage the archive drives, which
fills them up with the oldest recordings from the recording drives,
and also has an option to pack the archive drives when I have watched
and deleted a recording from them.  The pack operation moves files
from newer drives to older ones, so each drive has old recordings from
the same time period.  The software that does this ("mythsgu" = MythTV
Storage Group Utility) has a lot of code that detects what mythbackend
is doing and pauses its operations when anything is happening (a
recording in progress or due to start, playback of a recording, or
various other activity).

http://www.jsw.gen.nz/mythtv/mythsgu

If you want to do something like this and would like to try mythsgu,
please let me know and I can customise it for your requirements.  And
let you know how to install it properly so that it can see
mythbackend's activity.


More information about the mythtv-users mailing list