From: Eric Sandeen Subject: Re: Journal under-reservation bug on first >2G file Date: Thu, 02 Oct 2014 00:49:09 -0500 Message-ID: <542CE755.9040503@redhat.com> References: <542B1C38.9010409@redhat.com> <542B1EFC.4050500@redhat.com> <20141001115320.GA2903@thunk.org> <542C1314.3030603@redhat.com> <20141001195954.GD2903@thunk.org> <542C65FD.5040405@redhat.com> <20141001224325.GE2903@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Andreas Dilger , ext4 development To: "Theodore Ts'o" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:54115 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751211AbaJBFtM (ORCPT ); Thu, 2 Oct 2014 01:49:12 -0400 In-Reply-To: <20141001224325.GE2903@thunk.org> Sender: linux-ext4-owner@vger.kernel.org List-ID: On 10/1/14 5:43 PM, Theodore Ts'o wrote: > On Wed, Oct 01, 2014 at 03:37:17PM -0500, Eric Sandeen wrote: >> >> Ok. I guess this is only an issue for ext4 - well, at least this specific >> issue. Delalloc makes it much different than ext2 & ext3, which reserve quite a >> lot more. Whether there's a corner case over there which breaks, I dunno... >> >> So it seems like the simplest test is simply: Are we RW mounted with delalloc? >> And if so, update the feature. Seems simpler than mucking with "which features >> are unique to ext4" > > I'd do "are we RW mounted with the extents feature". That way we > don't need to worry about someone accidentally mounting a partition > meant for Hurd using ext4, which would imply delalloc, and then > causing Hurd to no longer be able to deal with the file system. That > *shouldn't* happen, but if someone accidentally mounts the file system > with -t ext4, but it seems safer to gate it on the existence of the > extents feature. Problem is, we can hit the same problem with an ext3 filesystem (no extents) mounted with -t ext4 (enabling delalloc). Ugh. Can't we just bump the da write reservation to 2 and be done with it? ;) (AFAICT the non-delalloc reservations can be wildly overestimated). Or maybe ext4_journal_extend() when we try to update the superblock? It could fail, but it wouldn't be catastrophic if it did, fsck would find that the feature is missing... -Eric