On Wed, Jun 06, 2018 at 03:27:11PM +0800, Qu Wenruo wrote: > The patchset can be fetched from github (*): > https://github.com/adam900710/btrfs-progs/tree/inline_ram_bytes > > It's based on David's devel branch, whose HEAD is: > commit 0d1c5812e28e286648781c7b35b542311cc01aa4 (david/devel) > Author: Matthias Benkard <matthias.benk...@egym.de> > Date: Wed Apr 25 16:34:54 2018 +0200 > > btrfs-progs: mkfs: traverse_directory: Reset error code on continue > > Reported-by Steve Leung <sjle...@shaw.ca>, his old btrfs (at least > offending inodes are from 2014) has inline uncompressed extent, while > its ram_bytes mismatch with item size. > > Latest kernel tree check catches this bug, while we failed to detect by > dump-tree. > > It turns out that btrfs-progs is doing something evil to avoid reading > ram_bytes from inline uncompressed extent. > > > So this patchset will address all such ram_bytes related problems.
Thanks, series applied. > The 1st patch is a not-so-relative fix for restore, which is using > ram_bytes for decompress. Although thanks to the compression header, we > won't read out-of-boundary, but fixing it is never a bad thing. > > The 2nd patch will get rid of the evil btrfs_file_extent_inline_len() > which hides raw ram_bytes from us, and fooling us for a long long time. > > The 3rd~5th patches introduce check/repair function for both original > and lowmem mode (although lowmem mode can detect it even before this patch). > > The last one is the test case for it as usual. > > *: Or should I just migrate to gitlab after M$ acquired github? About that, I have a gitlab account and auto-synced the btrfs-progs repository from github, so I guess it can be used to fork the code. The issues are disabled, that's kind of tied to github, but mail bugreports work and I think technically we don't have to stick to just one issue tracker though it's a bit of work on our side to update the status if the reports are duplicated. -- 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
