On Sat, Nov 18, 2017 at 1:15 AM, Nazar Mokrynskyi <nazar@xxxxxxxxxxxxxx> wrote: > I can assure you that drive (it is HDD) is perfectly functional with 0 SMART errors or warnings and doesn't have any problems. dmesg is clean in that regard too, HDD itself can be excluded from potential causes. > > There were however some memory-related issues on my machine a few months ago, so there is a chance that data might have being written incorrectly to the drive back then (I didn't run scrub on backup drive for a long time). > > How can I identify to which files these metadata belong to replace or just remove them (files)? You might look through the archives about bad ram and btrfs check --repair and include Hugo Mills in the search, I'm pretty sure there is code in repair that can fix certain kinds of memory induced corruption in metadata. But I have no idea if this is that type or if repair can make things worse in this case. So I'd say you get everything off this file system that you want, and then go ahead and try --repair and see what happens. One alternative is to just leave it alone. If you're not hitting these leaves in day to day operation, they won't hurt anything. Another alternative is to umount, and use btrfs-debug-tree -b on one of the leaf/node addresses and see what you get (probably an error), but it might still also show the node content so we have some idea what's affected by the error. If it flat out refuses to show the node, might be a feature request to get a flag that forces display of the node such as it is... -- Chris Murphy -- 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
