Hi Alex, On 13 March 2016 at 05:51, Alex Lyakas <[email protected]> wrote: > Nicholas, > > On Sat, Mar 12, 2016 at 12:19 AM, Nicholas D Steeves <[email protected]> > wrote: >> On 10 March 2016 at 06:10, Alex Lyakas <[email protected]> wrote: >> Does this mean there is a good chance that everyone has corrupted >> metadata? > No, this definitely does not. > > The code that I added prevents btrfs from writing a metadata block, if > it somehow got corrupted before being sent to disk. If it happens, it > indicates a bug somewhere in the kernel. For example, if some other > kernel module erroneously uses a page-cache entry, which does not > belong to it (and contains btrfs metadata block or part of it).
Oh wow, I didn't know that was possible. If I understand correctly, this patch makes using bcache a little bit safer? (I don't use it since I'm too short on free time to what is--I suspect-- something that radically increases the chances of having to restore from backup) >> Is there any way to verify/rebuild it without wipefs+mkfs+restore from >> backups? > To verify btrfs metadata: unmount the filesystem and run "btrfs check > ...". Do not specify the "repair" parameter. Another way to verify is > to run "btrfs-debug-tree" and redirect its standard output to > /dev/null. It should not print anything to standard error. But "btrfs > check" is faster. Ah, that's exactly what I was looking for! Thank you. It took forever, and brought me back to what it was like to fsck large ext2 volumes. Is btrfs check conceptually identical to a read-only fsck of a ext2 volume? If now how does it defer? Are the following sort of errors still an issue?: Extent back ref already exists for 2148837945344 parent 0 root 257 leaf parent key incorrect 504993210368 bad block 504993210368 ( https://btrfs.wiki.kernel.org/index.php/Btrfsck ) Cheers, Nicholas -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
