[mythtv-users] EXT4 vs XFS

[phipps-hutton at sky.com]

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.
Cheers,
Tim.