From: Theodore Ts'o Subject: Re: [PATCH 2/2] resize2fs: fix overhead calculation for meta_bg file systems Date: Wed, 5 Sep 2012 00:55:48 -0400 Message-ID: <20120905045548.GA29950@thunk.org> References: <20120903164525.GD5066@thunk.org> <1346690758-21072-1-git-send-email-tytso@mit.edu> <1346690758-21072-2-git-send-email-tytso@mit.edu> <20120904021412.GG5066@thunk.org> <504634D6.20608@iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Anssi Hannula , Kevin Liao , Ext4 Developers List To: Yongqiang Yang Return-path: Received: from li9-11.members.linode.com ([67.18.176.11]:48829 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750841Ab2IEEz7 (ORCPT ); Wed, 5 Sep 2012 00:55:59 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-ext4-owner@vger.kernel.org List-ID: On Wed, Sep 05, 2012 at 10:10:29AM +0800, Yongqiang Yang wrote: > Hi Anssi, > > The bug was fixed for a while, please check the patches: > [PATCH 1/2] ext4: teach resize report old blocks count correctly > [PATCH 2/2] ext4: ignore last group without enough space when resizing > > Please have a try!!! Yongqiang, In the future, if a patch is going to fix a BUG_ON or kernel crash, please state so explicitly in the commit description along with instructions about how to reproduce the problem. The urgency of a patch which (for example) fixes a debugging printk (such as your 1/2 patch above) is quite different from a patch which causes a kernel BUG_ON. One of the reasons why I hadn't gotten around to processing your patches until now was partially because I knew there was a lot of testing and fixing before the patches were fully baked (as soon as I started doing testing I found all sorts of other problems, which I had to fix), but also because the commit descriptions were not clear enough. Patches where it's obvious what they fix, and where there is a clear explanation about what they fix and the priority of their fix makes life easier for me, and makes it more likely that I can process the patches quickly. Also, if you have a follow-on set of patches which is dependent on the initila set of patches, it's very helpful to resend a v2 version of the patches so that it's clear how the patches fit together. I'll take care of these two extra patches, and then you'll see me send out a -v2 set of the patches which contain all of the online resize patches rebased to the latest kernel and tested as much as possible. In general, though, in order for me to scale, I really need ext4 developers to do as much of this testing, rebasing, and reposting patches as possible, and for other ext4 developers to review the patches. If I have to do all of this myself, patches will flow into mainline more slowly, and we'll start accumulating a much longer backlog. Regards, - Ted