Hi Roman,
On 03/10/16, Roman Mamedov wrote: > On Sun, 2 Oct 2016 13:29:56 -0600 > Chris Murphy <li...@colorremedies.com> wrote: > > > Well short of a bug, the problem aren't the checksums. The problem is > > the metadata is wrong, so if you recalculate checksums you're likely > > end up with an even more corrupted file system because it'll start out > > trusting bad metadata. > > It appears that metadata got created with profile "single", because the device > is SSD. If this was DUP metadata, this entire problem wouldn't happen. > It is a terrible idea to downgrade metadata to single on detecting SSDs at > mkfs. The original rationale was that "SSDs will deduplicate it anyways", but > there are many ways things can corrupt way before reaching the SSD (from the > point of view of which it will look like the computer sent two different > metadata blocks, if one got corrupted in flight), and secondly, the ability of > SSDs to perfectly deduplicate small 4K sized pieces of data at hundreds of > megabytes in read/write speeds is VASTLY overestimated here. I agree that the wear in SSDs due to metadata dublications is overestimated and since my partition appears to be screwed I will make sure next time to force it to have another copy there. My progress from the repairs which both failed are: https://ptpb.pw/CtbC Next step is initialize the extent tree btrfs check --init-extent-tree --repair /dev/sda3 Thanks, -- Leonidas Spyropoulos A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
