All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Andreas Dilger <adilger@dilger.ca>,
	ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: Journal under-reservation bug on first >2G file
Date: Thu, 02 Oct 2014 00:49:09 -0500	[thread overview]
Message-ID: <542CE755.9040503@redhat.com> (raw)
In-Reply-To: <20141001224325.GE2903@thunk.org>

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


  reply	other threads:[~2014-10-02  5:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-30 21:10 Journal under-reservation bug on first >2G file Eric Sandeen
2014-09-30 21:22 ` Eric Sandeen
2014-09-30 21:36   ` Andreas Dilger
2014-09-30 22:10     ` Darrick J. Wong
2014-10-01 11:53     ` Theodore Ts'o
2014-10-01 14:43       ` Eric Sandeen
2014-10-01 19:59         ` Theodore Ts'o
2014-10-01 20:37           ` Eric Sandeen
2014-10-01 22:43             ` Theodore Ts'o
2014-10-02  5:49               ` Eric Sandeen [this message]
2014-10-02 11:26                 ` Jan Kara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=542CE755.9040503@redhat.com \
    --to=sandeen@redhat.com \
    --cc=adilger@dilger.ca \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.