On Thu, Mar 25, 2021 at 6:00 AM Richard Shaw <hobbes1069@xxxxxxxxx> wrote:
>
> 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.
We don't have much control over when and how bugs manifest. It could
be true that drive firmware is improperly reordering 1 in 100 commits,
or only a particular sequence of flushing, or always. Such behavior
not a problem by itself, it takes a power fail or a crash to expose
the problem at just the right time. The whole point of write ordering
is to make sure the file system is consistent.
In the case of btrfs, the write order is simplistically:
data->metadata->flush/fua->superblock->flush/fua
What makes this safe with copy on write is no data or metadata is
overwritten, so there's no in between state. All the data writes in a
commit are represented by metadata (the btrees) in that commit, and
those trees aren't pointed to as current and valid until they are on
stable media. That's the point of the first flush. Then comes the
superblock which is what points to the new trees.
The problem happens if the super is written pointing to new trees
before all the metadata (or data) has arrived on stable media. And
then you get a power fail or crash. Now the super block is pointing to
locations that don't have consistent tree state and you get some
variation on mount failure.
>> 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?
hdparm -W0 but double check that, there's w and W and one of them
controls write cache, the other is dangerous.
$ cat /etc/udev/rules.d/69-hdparm.rules
ACTION=="add", SUBSYSTEM=="block", \
KERNEL=="sd*[!0-9]", \
ENV{ID_SERIAL_SHORT}=="WDZ47F0A", \
RUN+="/usr/sbin/hdparm -B 100 -S 252 /dev/disk/by-id/wwn-0x5000c500a93cae8a"
$
--
Chris Murphy
_______________________________________________
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
