From mboxrd@z Thu Jan 1 00:00:00 1970 From: Theodore Ts'o Subject: Re: Re: Reviewing ext3 improvement patches (delalloc, mballoc, extents) Date: Thu, 3 Mar 2005 17:10:10 -0500 Message-ID: <20050303221010.GB6140@thunk.org> References: <20050303083349.GA4896@in.ibm.com> <20050303094021.GY27352@schnapps.adilger.int> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Suparna Bhattacharya , ext2-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org, Alex Tomas Content-Disposition: inline In-Reply-To: <20050303094021.GY27352@schnapps.adilger.int> Sender: ext2-devel-admin@lists.sourceforge.net Errors-To: ext2-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: List-Id: linux-fsdevel.vger.kernel.org On Thu, Mar 03, 2005 at 02:40:21AM -0700, Andreas Dilger wrote: > > Well, for a starter, the extents format changes are not forced on > users, only if they mount with "-o extents" and write files will > it mark the superblock incompatible and start allocating files > this way. I believe (though I have never tested) that even if > extents are enabled, writes to a block-mapped file will continue > to work and that file will not be converted to an extent file. > I was about to start a new thread discussing this, but you started commenting about it here, so I'll address it here. The way most of the other ext3 extensions that involve feature changes work is that you enable them by using tune2fs (for example, "tune2fs -O dir_index /dev/hdaXX"), instead of using a mount option which then causes the kernel to automatically flip on an feature incompatble flag. It would be good if the extents were changed to follow this convention for the following reasons: 1) Consistency is less confusing for users, and features like dir_index, has_journal work this way already. 2) Long term, you don't want users to have to specify -o extents as a mount option, or specify "extents" in /etc/fstab in order to make the filesystem work correctly. From an initial examination of the extents code won't be initialized properly if you don't specify -o extents. So I'm pretty sure that if you try to mount a filesystem that has extents, but forget to specify -o extents, things will break in an entertaining fashion. I haven't yet tried it yet, though. 3) It means that users who are fooling around with the patch will have at least some kind of patched userspace first (or understand how to use debugfs to set the feature manually). This makes it less likely that they will apply the patch, or get it applied for free when they use the -mm tree (once the patches get accepted by Andrew), and then when they specify -o extents, all of sudden the filesystem becomes incompatible and no longer be mountable using standard tools. This is a bit of a pet peeve of mine, since I am still getting personal e-mail from people who were using Red Hat 7, and decided to just "try out" Fedora Core 3, only to find that any filesystems mounted by FC3 could no longer be mountable on their RH7 or RH8 systems. That's why I prefer users to have to do something that obviously acknowledges that they are making a change to their filesystem's compatibility prospects --- and that's something which is a lot more obvious with a "tune2fs -O " command, as compared to using a magic mount option. - Ted ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click