On Mon, Jan 4, 2021 at 10:27 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote:
On Sun, Jan 3, 2021 at 3:09 PM Richard Shaw <hobbes1069@xxxxxxxxx> wrote:
> On Sun, Jan 3, 2021 at 3:34 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote:
>> On Sun, Jan 3, 2021, 6:26 AM Richard Shaw <hobbes1069@xxxxxxxxx> wrote:
>
> Yeah, the RAID1 seems a lot easier with the caveat that the free space reporting is bogus, which may be important for a media drive. :) The RAID5 caveats don't scare me too much.
The odd number device raid1 free space reporting issue is 'df'
specific. If you try it out and fallocate a bunch of files 10G at a
time (no writes for fallocate, it's fast) you can see the goofy thing
that happens in the bug report. It isn't ever 100% wrong, but it is
confusing. The btrfs specific commands tell the truth always: btrf fi
df is short and sweet; btrfs fi us is very information dense.
Ok, so not so bad. The main reason I'm considering raid5 is that I have one 4TB drive right now, if I add 2 more with raid one, I'm only going to get 2TB. I know it's kind of a duh, you're mirroring and right now I have no redundancy, but this is for home use and $$$/TB is important and I can't fit any more drives in this case :)
Toss up on xxhash64, it's as fast or faster than crc32c to compute,
collision resistance, but csum algo is a mkfs time only option - only
reason why I mention it. I can write more upon request.
That's interesting. I hadn't read into the documentation that far yet. Are those the only two options?
If these are consumer drives: (a) timeout mismatch (b) disable each
drive's write cache. This is not btrfs specific advice, applies to
mdadm and LVM raid as well. Maybe someone has udev rules for this
somewhere and if not we ought to get them into Fedora somehow. hdparm
-W is the command, -w is dangerous (!). It is ok to use the write
cache if it's determined that the drive firmware honors flush/fua,
which they usually do, but the penalty is so bad if they don't and you
get a crash that it's maybe not worth taking the risk. Btrfs raid1
metadata helps here, as will using different drive make/models,
because if one drive does the wrong thing, btrfs self heals from
another drive even passively - but for parity raid you really ought to
scrub following a crash. Or hey, just avoid crashes :)
I guess I could test for this? The current drive is ext4 formatted so my original plan was to create a 2 drive raid1 and copy the files over, format the old drive and then add it to the array and rebalance (a +1 for raid1!). I could switch over to the 2 drive raid1 array for a while and "wait and see" or is there a more proactive method?
Obviously if I go raid5 I won't have this option unless I can temporarily house my data on a separate drive.
Looking at the link it looks like I'm OK?
# smartctl -l scterc /dev/sda1
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.9.16-200.fc33.x86_64] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org
SCT Error Recovery Control:
Read: 100 (10.0 seconds)
Write: 100 (10.0 seconds)
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.9.16-200.fc33.x86_64] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org
SCT Error Recovery Control:
Read: 100 (10.0 seconds)
Write: 100 (10.0 seconds)
The drive is a Seagate Terascale which is supposedly designed for cloud computing / datacenters.
So raid1 or raid5...
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
