Nicholas, On Sat, Mar 12, 2016 at 12:19 AM, Nicholas D Steeves <nstee...@gmail.com> wrote: > On 10 March 2016 at 06:10, Alex Lyakas <alex.bols...@gmail.com> wrote: >> csum_dirty_buffer was issuing a warning in case the extent buffer >> did not look alright, but was still returning success. >> Let's return error in this case, and also add an additional sanity >> check on the extent buffer header. >> The caller up the chain may BUG_ON on this, for example flush_epd_write_bio >> will, >> but it is better than to have a silent metadata corruption on disk. > > 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). > 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. Thanks, Alex. -- 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
