<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 5/21/20 3:08 AM, Jan Ceuleers wrote:<br>
</div>
<blockquote type="cite"
cite="mid:da2e7dcc-13c2-53e1-5c3d-fe8d4e00719f@gmail.com">
<pre class="moz-quote-pre" wrap="">On 21/05/2020 05:11, Stephen Worthington wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">And I was deliberately using weasel words as I have not been following
drive technology well enough to know for sure that drives will
guarantee being able to write their cache to journal space before
losing the power to do that. But that certainly seems to be what they
are aiming for. And I do not know at all whether drives receive and
act on fsync, or whether they choose to ignore that signal and keep on
doing their own caching. Or maybe they have an option you can set to
tell them which way to do things. Enterprise drives are more
configurable than desktop drives.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I suspect that on journaling filesystems fsync only guarantees that the
data has been committed to the journal (which is sufficient for ensuring
data integrity).
Unless you disable barriers.
<a class="moz-txt-link-freetext" href="http://fibrevillage.com/storage/565-what-s-barriers-how-to-enable-disable-it-on-linux">http://fibrevillage.com/storage/565-what-s-barriers-how-to-enable-disable-it-on-linux</a>
As I wrote before I run with disabled barriers. I can do that because my
server is powered through a UPS which gives it a few minutes of autonomy
in case of a power cut. In order to mitigate the risk that the server
might not shut down in time (which is a very small risk indeed) I enable
write barriers from apcupsd's onbattery script thusly:
while fs=`findmnt -l -t ext4 -O nobarrier --output=target --noheadings`
do
mount -o remount,barrier $fs
done
and disable them again if power returns before shutdown by means of the
following in the offbattery script:
while fs=`findmnt -s -l -t ext4 -O nobarrier --output=target --noheadings`
do
mount -o remount,barrier=0 $fs
done
Cheers, Jan
</pre>
</blockquote>
<p><br>
</p>
<p>A quick summary of what I got from this great discussion.</p>
<ol>
<li>Having a UPS on a Backend can make up for a lot of potential
issues. I have one.</li>
<li>WD Red NAS drives are a good blend of reliability and cost.</li>
<li>SSDs might be more reliable than we think, but when they fail
.....</li>
</ol>
<p>When I was testing and setting up a Backend for my RV/camper, I
used a RPi4 and SATA SSD and got into a discussion about drive
performance on the Raspberry. I added Quirks in my boot command
line and got performance like 155MB/s writes and 290MB/s reads on
very large sequential files. So SSD's in Backend use would be
overkill on performance for a 4-8 tuner setup. Key for the RV
backend is if it fails the recordings are also being done at home
also. The RV backend is just for convenience when on the road for
a few months. (I'll do anything to skip commercials when watching)<br>
</p>
<p>On my current home Backend using 2 sets of WD Red HDD mirrors I
have not seen any recordings tagged with recording problems
because of drive performance. It's always been tuner/antenna
issues. So I conclude that my normal record pattern isn't
stressing any hardware.<br>
</p>
<p>In the past 2 years I've only replaced 2 drives before switching
to WD Red when SMART warned me via email or mdadm said a drive
fell out of a mirror. The replacing of the drive and the resync
was painless. So I have never loss a recording due to hardware
failure, except when power was lost for a day due to a hurricane.
<br>
</p>
<p>So I can:</p>
<p>1. If it ain't broke, don't fix it. or</p>
<p>2. Redesign and rebuild everything to keep busy during Covid-19
stay at home orders.</p>
<p>Thanks,</p>
<p>Jim A</p>
<p><br>
</p>
<p>Jim A</p>
<p><br>
</p>
</body>
</html>