From: Theodore Tso <tytso@mit.edu>
To: Eric Sandeen <sandeen@redhat.com>,
Josef Bacik <jbacik@redhat.com>,
Akinobu Mita <akinobu.mita@gmail.com>,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
adilger@sun.com, li
Subject: Re: [PATCH] ext4: fix unhandled ext4_free_data allocation failure
Date: Mon, 12 Jan 2009 10:03:36 -0500 [thread overview]
Message-ID: <20090112150336.GE21793@mit.edu> (raw)
In-Reply-To: <20090112035835.GA16898@mit.edu>
On Sun, Jan 11, 2009 at 10:58:35PM -0500, Theodore Tso wrote:
> On Sun, Jan 11, 2009 at 08:46:32AM -0600, Eric Sandeen wrote:
> >
> > Well, this will now force a filesystem error (then remount-ro or panic
> > (or ignore) if the allocation fails. I'm not sure that's better...?
> >
>
> Well, our choices basically are:
>
> 1) Force a filesystem error
> 2) Sleep and retry the allocation
> 3) Don't add the freed blocks to the list regions that mballoc should
> be allowed to allocate from after the transaction commits. This
> results in the blocks getting "leaked" until the filesystem is
> mounted/unounted.
I just thought of another alternative:
4) Mark the buddy cache has being in need of being completely rebuilt
after the transaction commits.
Someone want to try coding that up?
- Ted
WARNING: multiple messages have this Message-ID (diff)
From: Theodore Tso <tytso@mit.edu>
To: Eric Sandeen <sandeen@redhat.com>,
Josef Bacik <jbacik@redhat.com>,
Akinobu Mita <akinobu.mita@gmail.com>,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
adilger@sun.com, linux-ext4@vger.kernel.org
Subject: Re: [PATCH] ext4: fix unhandled ext4_free_data allocation failure
Date: Mon, 12 Jan 2009 10:03:36 -0500 [thread overview]
Message-ID: <20090112150336.GE21793@mit.edu> (raw)
In-Reply-To: <20090112035835.GA16898@mit.edu>
On Sun, Jan 11, 2009 at 10:58:35PM -0500, Theodore Tso wrote:
> On Sun, Jan 11, 2009 at 08:46:32AM -0600, Eric Sandeen wrote:
> >
> > Well, this will now force a filesystem error (then remount-ro or panic
> > (or ignore) if the allocation fails. I'm not sure that's better...?
> >
>
> Well, our choices basically are:
>
> 1) Force a filesystem error
> 2) Sleep and retry the allocation
> 3) Don't add the freed blocks to the list regions that mballoc should
> be allowed to allocate from after the transaction commits. This
> results in the blocks getting "leaked" until the filesystem is
> mounted/unounted.
I just thought of another alternative:
4) Mark the buddy cache has being in need of being completely rebuilt
after the transaction commits.
Someone want to try coding that up?
- Ted
next prev parent reply other threads:[~2009-01-12 15:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-23 10:40 [PATCH] ext4: annotate unhandled kmem_cache_alloc() error Akinobu Mita
2008-12-23 14:29 ` Josef Bacik
2008-12-23 22:37 ` Akinobu Mita
2009-01-11 2:03 ` [PATCH] ext4: fix unhandled ext4_free_data allocation failure Akinobu Mita
2009-01-11 14:39 ` Josef Bacik
2009-01-11 14:46 ` Eric Sandeen
2009-01-12 3:58 ` Theodore Tso
2009-01-12 15:03 ` Theodore Tso [this message]
2009-01-12 15:03 ` Theodore Tso
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=20090112150336.GE21793@mit.edu \
--to=tytso@mit.edu \
--cc=adilger@sun.com \
--cc=akinobu.mita@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=jbacik@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sandeen@redhat.com \
/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.