Make sure to get NAS type drives. The non-Enterprise, Non-Nas drives usually won't timeout for 2-3 minutes. The NAS drives typically can be set 7 seconds or less. You also want to evaluate setting the timeout lower. And watch out for the SMR disks, get CMR ones. The SMR's are said to suck with both btrfs and raid. I have been using 3TB WD Reds, but got burned with the 1.5TB and 3TB seagates. 2 of 3 of my seagates 3TB did not make 3 years. My newest of my 6 3TB WD's are >3 years old and the oldest one is >7 and they only have a few bad blocks. Maybe the newer seagates are decent, but I got burned on 2 separate generations where a significant number had to be replaced and/or died under 4 years. And most of the replacements not last last more than 3 years. Given you will lose data when the machine reboots and aborts whatever is running, often disabling the write cache on the drive is not worth it unless you have critical data. Losing a few seconds of the recordings does not affect watching the shows for the most part. You might also want to get a 500gb ssd and record directly to that and move to the long term storage nightly. Mythtv syncs often and starts aborting recordings when it gets a few seconds behind. Basically anytime one of the drives blip, and once the drives get older that will happen from time to time and it is just easier to have it on the non-mirrored ssd. You could if you were really worried about leaving it on the ssd for a 24 hours setup a simple find takes to move any recording file that has not been modified in a few minutes. On Thu, Mar 25, 2021 at 7:00 AM Richard Shaw <hobbes1069@xxxxxxxxx> wrote: > > On Wed, Mar 24, 2021 at 11:26 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: >> >> On Wed, Mar 24, 2021 at 3:47 PM Richard Shaw <hobbes1069@xxxxxxxxx> wrote: >> > >> > I've been running MythTV for about 10 years now and I've finally outgrown my media storage, currently a single 4TB disk drive. I have purchased 3 additional drives of the same model and plan to put them into a BTRFS RAID1 array. >> > >> > Setting nodatacow on the media directories is a no-brainer, but what other optimizations can I do? >> >> nodatacow means nodatasum and no compression. If the file becomes >> corrupt, it can't be detected or corrected. > > > Ok, so that may be a problem. I'm not worried about compression since it's all MPEG2/H264 files anyway but the nodatasum would defeat the purpose... > >> >> >> Due to all the firmware bugs, I tend to mix make/model drives rather >> than get the same ones that are all going to have the same bug at the >> time time if something goes wrong like a power fail or crash right >> after going a bunch of writes. Whereas separate bugs, btrfs can always >> do fix ups from the good drive whenever the bad one misbehaves. > > > So how long do you wait until you consider the drive "good"? :) > > I'm not in a hurry so I could setup two of the drives in a RAID1 mirror and copy my media over and just let it run for a while before I add disks 3 & 4. > >> >> If they've proven their reliability in case of crash or power fail, as >> in start doing a big file(s) copy, and yank power on all the drives at >> once: Reboot. Reattach the drives. Remount. Any errors? Does it >> mount? If you can do this 10x without errors, it might be OK. > > > Regardless of which computer it is in the house, critical stuff is backed up on a BackupPC server and the super critical stuff also backed up on multiple cloud services (Google Drive, SpiderOak, Dropbox, etc), although it has been a while since I burned a disc and put it in the fire safe :) > > I would hate to lose all the media but it wouldn't be the end of the world for me so I think 10x is good enough :) > >> Still, I'd probably opt to set a udev rule for all the drives and >> disable the write cache. It isn't worth the trouble. > > > I know you mentioned this on another thread but google is failing me as to how to do it. Do you have a useful link? > > Thanks, > Richard > _______________________________________________ > users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
