[mythtv-users] EXT4 vs XFS
phipps-hutton at sky.com
phipps-hutton at sky.com
Thu Nov 17 10:24:49 UTC 2011
Quoting Mark Lord <mythtv at rtr.ca>:
> For the most part, very few of us would ever really want to
> have "on the fly TRIM" enabled. Which is why it's off by default,
> and most kernel developers want it off by default.
Well I'm not a kernel developer and I wouldn't recommend running
MythTV on the same machine as doing kernel development, TV is just too
important. I'd also assume that the kernel developers that wrote the
TRIM support have it on but perhaps I'm being naive.
> It slows things down and adds unnecessary wear and tear (aka. "erase cycles")
> to the SSDs for very little, if any, real-life benefit.
I disagree with the above, let's split it into two.
Wear and tear:
TRIM support means that the kernel tells the drive controller that a
sector is unused and the kernel will not expect the sector contents to
be preserved. That's all it does. SSD controllers use this information
to erase the sectors and put them on the list of erased sectors. They
do this when they have nothing to do and they maintain the list in
permanent storage. When the kernel writes over a sector the controller
will write the sector contents to a sector from the erased list if
there is one and put the old sector on the list of
to-be-erased-sectors for later processing. If there aren't any erased
sectors the controller will have to erase the sector before writing
which is much slower.
Whichever method is used to write the sector one sector is erased and
one sector is written. The difference is in the order and which
particular sectors are written. Using TRIM support gives the
controller an easier time of wear leveling.
Slows things down:
TRIM support was put in because SSD disks slow down after a while if
you don't have it. When you buy a new SSD all the sectors are on the
erased list and it writes like a demon.... until you have written more
than one disks worth which in real life happens after a few days.
After that if you don't have TRIM support there won't be any sectors
on the erased list and each write will require an erase first and
performance will drop off. From personal experience turning on TRIM
support speeds things up (or rather stops the slowing down gradually).
I guess if you are running something truly disk trashing a brand new
disk will outperform one that has been running a long time with TRIM
(the erases have to be done eventually) but you shouldn't be expecting
MythTV to work on such a system. you should have some write
performance margin or you will fail to record something eventually and
TV is too important.
> Doing periodic batched TRIMs is better, either with one of the various
> programs that support FSTRIM, or with the wiper.sh script that is
> part of the hdparm package. Note that the latter works for ext3 as well,
> in an "offline" (non-mounted) mode.
Agreed about wiper.sh working but you have to factor the downtime in
to your calculations. You are effectively preventing the controller
from erasing when it is not busy and doing all the erases at your
convenience. You run the risk that write performance will degrade just
when you need it. i.e. all those films shown at Christmas and you just
don't have time to log in and run the wiper scripts.
If you're worried about the controller erasing the wrong stuff you can
always checksum your files. I used to use AIDE for this and it works
pretty well. I run MD5 on the root (SSD partition) every night and the
TV disk (non-SSD but they fail too) once a week before I run the
backup. I've had an Intel X25V running since you could first buy them
and it has not failed yet. The big conventional disk has in the past
and it got replaced.
Sorry about the lengthy post.
More information about the mythtv-users