[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <4206D78A-FD6D-4F3E-8CD1-5D717784BCA8@dilger.ca>
Date: Fri, 13 Jun 2014 15:45:03 -0600
From: Andreas Dilger <adilger@...ger.ca>
To: "Darrick J. Wong" <darrick.wong@...cle.com>
Cc: Akira Fujita <a-fujita@...jp.nec.com>,
Theodore Tso <tytso@....edu>,
Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 3/3] mke2fs: prevent creation of unmountable ext4 with large flex_bg count
On Jun 12, 2014, at 5:50 PM, Darrick J. Wong <darrick.wong@...cle.com> wrote:
> On Wed, Jun 11, 2014 at 01:01:29PM -0600, Andreas Dilger wrote:
>>
>> This also reminds me of my previous flex_bg patch:
>> [PATCH][RFC] mke2fs: handle flex_bg collision with backup descriptors
>> http://permalink.gmane.org/gmane.comp.file-systems.ext4/42298
>>
>> which fixes the "bmap-imap-itable-bmap-imap-itable" problem when a large
>> flex_bg size is used. Sadly, there were no comments on that patch.
>
> I had wondered if you were planning to address the FIXMEs in the patch, but
> then forgot to ever follow up... :/
Well, I was thinking that the patch was good enough to land as-is. It fixes 99% the problem for flex_bg size up to 65536, but only 95% of the groups for flex_bg of 131072. I guess I'll send it out again without [RFC], and if people start using flex_bg >= 131072 (which is enough for all the metadata in a 16TB chunk) then we can work out the final details. I suspect that the sparse_super2 feature would probably become more prevalent and avoid this problem entirely.
Cheers, Andreas
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists