Ok this output looked fishy and so I went and tested it on my box again. It looks like I wasn't testing modifying a snapshot with an existing fs so I never saw these errors, but I see them as well. I definitely fucked the building of the initial ref tree. It's too late tonight for me to rework it and have it working for you, but I should be able to get it into shape in the morning. I'll let you know when I have something useful to test, sorry about the mess,
Josef Sent from my iPhone > On Sep 3, 2017, at 4:21 PM, Marc MERLIN <m...@merlins.org> wrote: > >> On Sun, Sep 03, 2017 at 05:33:33PM +0000, Josef Bacik wrote: >> Alright pushed, sorry about that. > > I'm reasonably sure I'm running the new code, but still got this: > [ 2104.336513] Dropping a ref for a root that doesn't have a ref on the block > [ 2104.358226] Dumping block entry [115253923840 155648], num_refs 1, > metadata 0, from disk 1 > [ 2104.384037] Ref root 0, parent 3414272884736, owner 262813, offset 0, > num_refs 18446744073709551615 > [ 2104.412766] Ref root 418, parent 0, owner 262813, offset 0, num_refs 1 > [ 2104.433888] Root entry 418, num_refs 1 > [ 2104.446648] Root entry 69869, num_refs 0 > [ 2104.459904] Ref action 2, root 69869, ref_root 0, parent 3414272884736, > owner 262813, offset 0, num_refs 18446744073709551615 > [ 2104.496244] No Stacktrace > > Now, in the background I had a monthly md check of the underlying device > (mdadm raid 5), and got some of those. Obviously that's not good, and > I'm assuming that md raid5 may not have a checksum on blocks, so it won't know > which drive has the corrupted data. > Does that sound right? > > Now, the good news is that btrfs on top does have checksums, so running a > scrub should > hopefully find those corrupted blocks if they happen to be in use by the > filesystem > (maybe they are free). > But as a reminder, this whole thread started with my FS maybe not being in a > good state, but both > check --repair and scrub returning clean. Maybe I'll use the opportunity to > re-run a check --repair > and a scrub after that to see what state things are in. > > md6: mismatch sector in range 3581539536-3581539544 > md6: mismatch sector in range 3581539544-3581539552 > md6: mismatch sector in range 3581539552-3581539560 > md6: mismatch sector in range 3581539560-3581539568 > md6: mismatch sector in range 3581543792-3581543800 > md6: mismatch sector in range 3581543800-3581543808 > md6: mismatch sector in range 3581543808-3581543816 > md6: mismatch sector in range 3581543816-3581543824 > md6: mismatch sector in range 3581544112-3581544120 > md6: mismatch sector in range 3581544120-3581544128 > > As for your patch, no idea why it's not giving me a stacktrace, sorry :-/ > > Git log of my tree does show: > commit aa162d2908bd7452805ea812b7550232b0b6ed53 > Author: Josef Bacik <jba...@fb.com> > Date: Sun Sep 3 13:32:17 2017 -0400 > > Btrfs: use be->metadata just in case > > I suspect we're not getting the owner in some cases, so we want to just > use the known value. > > Signed-off-by: Josef Bacik <jba...@fb.com> > > Marc > -- > "A mouse is a device used to point at the xterm you want to type in" - A.S.R. > Microsoft is to operating systems .... > .... what McDonalds is to gourmet cooking > Home page: > https://urldefense.proofpoint.com/v2/url?u=http-3A__marc.merlins.org_&d=DwIBAg&c=5VD0RTtNlTh3ycd41b3MUw&r=sDzg6MvHymKOUgI8SFIm4Q&m=BaH33jtavN-1wWyV3yseE5v7ImIAaTXLnjChSr4HnQw&s=3JczS4Mo254uip2aIsYiC_EUHsmGYcCJUUMl6si8NQ8&e= > | PGP 1024R/763BE901 -- 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
