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:25:31 -0400 Message-ID: <448992EB.5070405@garzik.org> References: <1149816055.4066.60.camel@dyn9047017069.beaverton.ibm.com> <4488E1A4.20305@garzik.org> <20060609083523.GQ5964@schatzie.adilger.int> <44898EE3.6080903@garzik.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Andrew Morton , Linus Torvalds , cmm@us.ibm.com, Andreas Dilger Return-path: To: linux-kernel@vger.kernel.org, ext2-devel , linux-fsdevel@vger.kernel.org In-Reply-To: <44898EE3.6080903@garzik.org> 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 Overall, I'm surprised that ext3 developers don't see any of the problems related to progressive, stealth filesystem upgrades. Users are never given a clear indication of when their metadata is being upgraded, there is no clear "line of demarcation" they cross, when they start using extents. Since there is no user-visible fs upgrade event, users do not have a clear picture of what features are being used -- which means they are kept in the dark about which kernels are OK to use on their data. Do you guys honestly expect users to keep track of which kernels added specific ext3 features? This is why other enterprise filesystems have clear "fs version 1", "fs version 2" points across which a user migrates. ext3's feature-flags approach just means that there are a million combinations of potential old-and-new features, in-tree and third party, all of which must be supported. Jeff