On Tue, 8 Jul 2014, Theodore Ts'o wrote: > Date: Tue, 8 Jul 2014 08:54:54 -0400 > From: Theodore Ts'o <tytso@xxxxxxx> > To: Lukáš Czerner <lczerner@xxxxxxxxxx> > Cc: Ext4 Developers List <linux-ext4@xxxxxxxxxxxxxxx>, stable@xxxxxxxxxxxxxxx > Subject: Re: [PATCH] ext4: clarify ext4_error message in > ext4_mb_generate_buddy_error() > > On Tue, Jul 08, 2014 at 09:03:48AM +0200, Lukáš Czerner wrote: > > > > It is a bit better, even though strictly speaking it's not > > right, because it is not block bitmap alone, but rather aggregation > > of block bitmap and preallocations. But for the user this is really > > an implementation detail they do not need to worry about I guess. > > Actually, no, because the preallocations aren't reflected in the > in-block bitmap. But the "bitmap" argument we're getting in ext4_mb_generate_buddy() is not just the original on disk bitmap, is it ? It's aggregation of the on on disk block bitmap and preallocation (this is done in ext4_mb_init_cache()). Or am I missing something ? > > And, oh sh*t, I wonder if that's the cause of the > ext4_mb_generate_buddy(). We don't need the buddy bitmaps to allocate > out of the preallocations, and it's not needed by > ext4_mb_mark_diskspace_used(). If the buddy bitmaps have been pushed > out of the page cache between when the blocks were originally > preallocated and when we try to use some preallocated blocks, and then > we have a race between ext4_mb_mark_diskspace_used() and > ext4_mb_buddy_generate(), that could explain the discrepancy between > the block group descriptors and the loaded buddy bitmap. ext4_mb_generate_buddy() is run under the group lock and the actual ext4_set_bits() in ext4_mb_mark_diskspace_used as well. And again in ext4_mb_generate_buddy() we do take into account preallocations which will be marked as used in the buddy bitmap. > > If this is what's going on, it doesn't explain why we hacen't been > seeing this until post 3.15, though.... > > - Ted > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html >
