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 14:48:32 -0400 Message-ID: <4489C280.2090607@garzik.org> References: <1149816055.4066.60.camel@dyn9047017069.beaverton.ibm.com> <20060609091327.GA3679@infradead.org> <44898476.80401@garzik.org> <4489874C.1020108@garzik.org> <44899113.3070509@garzik.org> <20060609165643.GA5964@schatzie.adilger.int> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: To: Jeff Garzik , Alex Tomas , Christoph Hellwig , linux-fsdevel@vger.kernel.org, ext2-devel , Mingming Cao , linux-kernel@vger.kernel.org In-Reply-To: <20060609165643.GA5964@schatzie.adilger.int> 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 Andreas Dilger wrote: > Except that the only way that they will get extents is if they read some > documentation that tells them to mount with "-o extents", which will also > say "this is incompatible with older kernels - only use it if you aren't > going to revert to older kernels". If they try to mount such a filesystem > it will report "trying to mount filesystem with incompatible feature", > and "e2fsprogs" will report "incompatible feature extents - please upgrade > your e2fsprogs" (for versions newer than Nov 2004). False. What will happen is that distros will default to extents, and users will continue to not read documentation, as usual. > It's a lot better than e.g. the latest ubuntu which (apparently, > I read) can't mount a kernel older than 2.6.15 because of udev (or > sysfs?) changes. It's better than e.g. reiserfs vs. reiser4 compatibility > (which doesn't exist). 2.4 kernels probably can't mount a new udev root > filesystem because none of the /dev files exist either. 2.4 kernels can't > mount a filesystem that is using device mapper ("LVM 2.0") instead of > "LVM 1.0". All 2.2 kernel.org kernels couldn't use any system with RAID, > because any distro worth its salt had upgraded the RAID code to a working > (incompatible) version. This is different. The proposal is to change the thing called "ext3" to suddenly require kernels >= 2.6.18, while still calling it "ext3." The above examples are actually proving my point. The above examples had much more clear distinctions between incompatible upgrades. > Nobody is forcing users to use extents. Same with large inodes in ext3, > which give a 7x speedup in samba4 performance - did this cause you any > heartburn yet? Large inodes + fast EAs are available for people who want > to use it for a couple of years already, will soon allow nanosecond times > and maybe one day in the distant future it will become the default but not > yet. In a few years, the support for extents in ext3 will be pervasive > and most people won't care if they can boot to 2.4.10 or not, and if they > care about this they will also know enough not to enable extents. The ext3 > developers are a very cautious bunch, and don't force anything onto users. I wouldn't use the word "cautious" to describe continually adding new, incompatible features to the main Linux filesystem. You are as cautious as one can be, while adding potentially destabilizing features. Jeff