On 2020/1/10 上午9:40, Qu Wenruo wrote: > > > On 2020/1/9 下午10:21, Josef Bacik wrote: >> On 1/9/20 2:16 AM, Qu Wenruo wrote: >>> When btrfs_update_device() failed due to ENOMEM, we didn't reset device >>> size back to its original size, causing the in-memory device size larger >>> than original. >>> >>> If somehow the memory pressure get solved, and the fs committed, since >>> the device item is not updated, but super block total size get updated, >>> it would cause mount failure due to size mismatch. >>> >>> So here revert device size and super size to its original size when >>> btrfs_update_device() failed, just like what we did in shrink_device(). >>> >>> Signed-off-by: Qu Wenruo <wqu@xxxxxxxx> >> >> Did you test this with error injection to make sure nothing else wonky >> came out of this? If you are going to fix this I'd rather it be in a >> different series because it's not necessarily related to what you are >> doing, and isn't any more broken with your other patches. The thing you >> are fixing in this series is important and I'd rather not hold it up on >> some error handling shenanigans. Thanks, > > Yes, I have the same feeling. > > But sometimes I just can't stop addressing the comment that makes sense. > > And you're right, I forgot the error injection test, and it detects one bug. > In the error handling path, I forgot the re-update per-profile > available, causing df showing the grown size, not the old size. > > To David, what's your idea on this? > I guess the patchset can't be backported anyway due to new infrastructure. > I'm OK solving the problem by either removing this patch, or fix the bug > exposed by the error injection. Gentle ping. Any feedback, David? Thanks, Qu > > Thanks, > Qu > >> >> Josef >
Attachment:
signature.asc
Description: OpenPGP digital signature
