[mythtv-users] Filesystem of choice for recording drive?

[Warpme]

On 21/01/15 23:45, Simon Hobson wrote:
> Warpme <warpme at o2.pl> wrote:
>
>> A: traditional drive (i.e. WD Green)
>> 1.app reads sector
>> 2.CRC errors discovered
>> 3.HDD controller rereads bad sector multiple times with hope that drive CRC algorithm redundancy data will recover error.
>>
>> B:AV streaming optimized drive (i.e. WD Purple)
>> 1.app reads sector
>> 2.CRC arrors discovered
>> 3.HDD rereads sector only few times with hope that drive CRC redundancy data will recover error. When fails - read operation ends with success but HDD returns bad data!!!
>>
>> Now:
>> A.3 can be 10..60sec or even more.
>> B.3: can be let say 0.5sec (time in which HDD cache can buffer incomming write data when write to platters is blocked by read recovery)
>>
>> As 3 is write blocking, we can say:
>> WD Green will damage recording for hope of getting glitch-free playback
>> WD Purple will try keep recording with price of glitches in playback
>>
>> What is better for myth recording drive?
> The latter is fine *IFF* the corruption isn't in the filesystem data.
Well, for me WD Purple case I described is exactly the same like 
bitroting from FS point of view.
Bitroting is well known and widely present in magnetic HDD.
By this, majority filesystems have integrity checks for metadata and 
algorithms to deal with this.
In this exactly context, AV streaming HDDs causing the same problems 
like standard HDD drivers - but for sure frequency of such problems is 
higher. This is price for much better behavior of such drives for 
real-time writing apps.
I'm not sure how exactly Ext/XFS/etc implementing metadata protection 
for bitroting - but I'm pretty  sure there are strong mechanisms to deal 
with...

> So while you might not care too much about a glitch in the recording, you probably do care a lot about glitches in the filesystem data that will corrupt the filesystem.
> Or, getting a read or write error and having the filesystem unmounted dirty (or whatever the OS does in that case).
>
> I wouldn't assume that such a behaviour isn't without it's own issues.
Sure it has.
Algorithm to prevent metadata corruption by bitroting is used much more 
frequently - so probability there will be corner case when it fails is 
much higher...
It will be good to understand how major FS are dealing with bitroting.
ZFS/BTRFS are designed with this issue in mind.
Some details: 
http://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/