From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Garzik Subject: Re: [RFC 0/13] extents and 48bit ext3 Date: Fri, 09 Jun 2006 11:56:12 -0400 Message-ID: <44899A1C.7000207@garzik.org> References: <1149816055.4066.60.camel@dyn9047017069.beaverton.ibm.com> <4488E1A4.20305@garzik.org> <20060609083523.GQ5964@schatzie.adilger.int> <44898EE3.6080903@garzik.org> <448992EB.5070405@garzik.org> <448997FA.50109@garzik.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Andrew Morton , ext2-devel , linux-kernel@vger.kernel.org, Linus Torvalds , cmm@us.ibm.com, linux-fsdevel@vger.kernel.org, Andreas Dilger Return-path: To: Alex Tomas In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ext2-devel-bounces@lists.sourceforge.net Errors-To: ext2-devel-bounces@lists.sourceforge.net List-Id: linux-fsdevel.vger.kernel.org Alex Tomas wrote: >>>>>> Jeff Garzik (JG) writes: > > JG> think about The Experience: Suddenly users that could use 2.4.x and > JG> 2.6.x are locked into 2.6.18+, by the simple and common act of writing > JG> to a file. > > sorry to repeat, but if they simple try 2.6.18, they won't get extents. > instead, they must specify extents mount option. and at this point > they must get clear that this is a way to get incompatible fs. Think about how this will be deployed in production, long term. If extents are not made default at some point, then no one will use the feature, and it should not be merged. And when extents are default, you have this blizzard-of-feature-flags stealth upgrade event occur _sometime_ after they boot into the new fs for the first time. And then when they want to boot another kernel, they have to dig down a feature matrix, and figure out which ext3 codebase will work for them. Jeff