All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Nick Piggin <npiggin@kernel.dk>
Cc: Jan Kara <jack@suse.cz>, Chris Mason <chris.mason@oracle.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	linux-ext4 <linux-ext4@vger.kernel.org>,
	linux-btrfs <linux-btrfs@vger.kernel.org>,
	Eric Sandeen <sandeen@redhat.com>,
	"Theodore Ts'o" <tytso@mit.edu>
Subject: Re: [patch] fs: fix deadlocks in writeback_if_idle
Date: Mon, 29 Nov 2010 14:26:03 -0800	[thread overview]
Message-ID: <20101129142603.ebbcbc7e.akpm@linux-foundation.org> (raw)
In-Reply-To: <20101125035356.GC3359@amd>

	On Thu, 25 Nov 2010 14:53:56 +1100
Nick Piggin <npiggin@kernel.dk> wrote:

> On Wed, Nov 24, 2010 at 02:10:28PM +0100, Jan Kara wrote:
> > On Wed 24-11-10 12:03:43, Nick Piggin wrote:
> > > > For the _nr variant that btrfs uses, it's worse for the filesystems
> > > > that don't have a 1:1 bdi<->sb mapping.  It might not actually write any
> > > > of the pages from the SB that is out of space.
> > > 
> > > That's true, but it might not write anything anyway (and after we
> > > check whether writeout is in progress, the writeout thread could go
> > > to sleep and not do anything anyway).
> > > 
> > > So it's a pretty hacky interface anyway. If you want to do anything
> > > deterministic, you obviously need real coupling between producer and
> > > consumer. This should only be a performance tweak (or a workaround
> > > hack in worst case).
> >   Yes, the current interface is a band aid for the problem and better
> > interface is welcome. But it's not trivial to do better...
> > 
> > > > > It makes no further guarantees, and anyway
> > > > > the sb has to compete for normal writeback within this bdi.
> > > > 
> > > > > 
> > > > > I think Christoph is right because filesystems should not really
> > > > > know about how bdi writeback queueing works. But I don't know if it's
> > > > > worth doing anything more complex for this functionality?
> > > > 
> > > > I think we should make a writeback_inodes_sb_unlocked() that doesn't
> > > > warn when the semaphore isn't held.  That should be enough given where
> > > > btrfs and ext4 are calling it from.
> > > 
> > > It doesn't solve the bugs -- calling and waiting for writeback is
> > > still broken because completion requires i_mutex and it is called
> > > from under i_mutex.
> >   Well, as I wrote in my previous email, only ext4 has the problem with
> > i_mutex and I personally view it as a bug. But ultimately it's Ted's call
> > to decide.
> 
> Well, for now, the easiest and simplest fix is my patch, I think. The
> objection is that we may not write out anything for the specified sb,
> but the current implementation provides no such guarantees at all
> anyway, so I don't think it's a big issue.

Well yes.  We take something which will fail occasionally and with your
patch replace it with something which will fail a bit more often.  Why
don't we go all the way and do something which will fail *even more
often*.  Namely, just delete the damn function in the hope that the
resulting failures will provoke the ext4 crew into doing something sane
this time?

Guys, this delalloc thing *sucks*.  And here we are just sticking new
bandaids on top of the old bandaids.  And the btrfs approach isn't
exactly a thing of glory, either.

So...  nope.  I won't be applying Nick's patch.  Please fix this thing
properly - you have a whole month!

  reply	other threads:[~2010-11-29 22:26 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-23 10:02 [patch] fs: fix deadlocks in writeback_if_idle Nick Piggin
2010-11-23 10:11 ` Nick Piggin
2010-11-23 13:18   ` Jan Kara
2010-11-25  3:52     ` Nick Piggin
2010-11-23 10:26 ` Boaz Harrosh
2010-11-23 10:54   ` Nick Piggin
2010-11-23 12:00     ` Boaz Harrosh
2010-11-23 12:34 ` Chris Mason
2010-11-23 12:52   ` Nick Piggin
2010-11-23 18:58     ` Chris Mason
2010-11-24  1:03       ` Nick Piggin
2010-11-24 13:10         ` Jan Kara
2010-11-25  3:53           ` Nick Piggin
2010-11-29 22:26             ` Andrew Morton [this message]
2010-11-30  0:01               ` Nick Piggin
2010-12-16  3:12                 ` Nick Piggin
2010-11-24 22:51         ` Andrew Morton
2010-11-25  4:07           ` Nick Piggin
2010-11-24 22:47   ` Andrew Morton
2010-11-25  9:41     ` Boaz Harrosh
2010-11-25 20:30       ` Andrew Morton
2010-11-30  0:50     ` Chris Mason
2010-11-23 12:54 ` Dmitry
2010-11-23 12:54 ` Dmitry

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=20101129142603.ebbcbc7e.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=chris.mason@oracle.com \
    --cc=jack@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=npiggin@kernel.dk \
    --cc=sandeen@redhat.com \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    /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.