I have read the analysis on data corruption in disks setups. From what I can tell they are using incorrect assumptions and models and the estimates of risk are a fair number of orders of higher that is actually the case. Because of that I am not that worried about the risks to my data. If I lose a few blocks of data it is not the end of the world and there is a performance impact. The data I have would be annoying to lose parts of it, but it is only annoying. I have been managing large environments for 20+ years with 1000's petabyte years. I have seen a total of 3 events where undetected corruptions happened, and the way they were detected makes it pretty unlikely there are more than 2x that number of undetected corruptions total in the environment. One was a pci controller being bad corrupting reads (confirmed writes failed at least 100x less). One was a pci bus set too fast corrupting reads (confirmed writes failed at least 100x less). The 3rd was the worst. It was an enterprise/near enterprise 1st vendor array where a very small number (5 out of 1000's of ssds) would reboot/reset unexpectedly when not completely written data in them. And I believe they did have the drive write caches disabled, but the way the SSD's firmware worked if it lost power at the wrong time the data was not yet really written and was lost. The 5 disks themselves seem to be broken. The biggest mistake the vendor made was not immediately booting off the array any device that randomly "rebooted" and or reset without being told to. On Mon, Apr 5, 2021 at 12:29 PM antlists <antlists@xxxxxxxxxxxxxxx> wrote: > > On 05/04/2021 12:30, Roger Heflin wrote: > >> diskfarm:~ # grep /mnt/ssd /etc/fstab > >> LABEL=diskfarm-ssd /mnt/ssd xfs defaults 0 0 > >> > >> will work for my bitmap files target, since all I see is that it must be > >> an ext2 or ext3 (not ext4? old news?) device. > > Bear in mind you're better off using a journal (and bitmaps and journals > are incompatible). > > "not ext4" seems odd to me because - from a kernel point of view - ext's > 2 and 3 no longer longer exist. > >> > > I don't know, I have always done mine internal. I could see some > > advantage to have it on a SSD vs internally. I may have to try that, > > I am about to do some array reworks to go from all 3tb disks to start > > using some 6tb disks. If the file was pre-allocated I would not > > think it would matter which. The page is dated 2011 so that would > > have been old enough that no one tested ext4/xfs. > > > Umm... don't use all the space on your 6TB disks. I'm planning to build > my arrays on dm-integrity, which will make raid 5 a bit more trustworthy. > > > I was going to tell you you could just create a LV and format it ext3 > > and use it, but I see it appears you are using direct partitions only. > > Ny new system? 4TB disks, with one terabyte raided and lvm on top for > root partitions (I'll be configuring it multi-boot or VMs...). Then > three terabytes with dm-integrity at the bottom, then raid, then lvm on > top for /home and backup snapshots. > > Cheers, > Wol
