On Tue, Aug 01, 2017 at 11:04:10AM +0500, Roman Mamedov wrote: > On Mon, 31 Jul 2017 11:12:01 -0700 > Liu Bo <bo.li.liu@xxxxxxxxxx> wrote: > > > Superblock and chunk tree root is OK, looks like the header part of > > the tree root is now all-zero, but I'm unable to think of a btrfs bug > > which can lead to that (if there is, it is a serious enough one) > > I see that the FS is being mounted with "discard". So maybe it was a TRIM gone > bad (wrong location or in a wrong sequence). > By checking discard path in btrfs, looks OK to me, more likely it's caused by problems from underlying stuff. Thanks, -liubo > Generally it appears to be not recommended to use "discard" by now (because of > its performance impact, and maybe possible issues like this), instead schedule > to call "fstrim <mountpoint>" once a day or so, and/or on boot-up. > > > on ssd like disks, by default there is only one copy for metadata. > > Time and time again, the default of "single" metadata for SSD is a terrible > idea. Most likely DUP metadata would save the FS in this case. > > -- > With respect, > Roman > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
