From: Jan Kara <jack@suse.cz>
To: Jens Axboe <jens.axboe@oracle.com>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
chris.mason@oracle.com, hch@infradead.org, tytso@mit.edu,
akpm@linux-foundation.org, jack@suse.cz,
trond.myklebust@fys.uio.no
Subject: Re: [PATCH 10/11] writeback: splice dirty inode entries to default bdi on bdi_destroy()
Date: Wed, 16 Sep 2009 15:12:49 +0200 [thread overview]
Message-ID: <20090916131249.GG26030@duck.suse.cz> (raw)
In-Reply-To: <1253038617-30204-11-git-send-email-jens.axboe@oracle.com>
On Tue 15-09-09 20:16:56, Jens Axboe wrote:
> We cannot safely ensure that the inodes are all gone at this point
> in time, and we must not destroy this bdi with inodes having off it.
^^^ hanging
> So just splice our entries to the default bdi since that one will
> always persist.
BTW: Why can't we make sure all inodes on the BDI are clean when we
destroy it? Common sence would suggest that we better should be able to do
it :).
Maybe it's because most users of private BDI do not call bdi_unregister
but rather directly bdi_destroy? Is this correct behavior?
Honza
> Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
> ---
> mm/backing-dev.c | 14 +++++++++++++-
> 1 files changed, 13 insertions(+), 1 deletions(-)
>
> diff --git a/mm/backing-dev.c b/mm/backing-dev.c
> index fd93566..3d3accb 100644
> --- a/mm/backing-dev.c
> +++ b/mm/backing-dev.c
> @@ -668,7 +668,19 @@ void bdi_destroy(struct backing_dev_info *bdi)
> {
> int i;
>
> - WARN_ON(bdi_has_dirty_io(bdi));
> + /*
> + * Splice our entries to the default_backing_dev_info, if this
> + * bdi disappears
> + */
> + if (bdi_has_dirty_io(bdi)) {
> + struct bdi_writeback *dst = &default_backing_dev_info.wb;
> +
> + spin_lock(&inode_lock);
> + list_splice(&bdi->wb.b_dirty, &dst->b_dirty);
> + list_splice(&bdi->wb.b_io, &dst->b_io);
> + list_splice(&bdi->wb.b_more_io, &dst->b_more_io);
> + spin_unlock(&inode_lock);
> + }
>
> bdi_unregister(bdi);
>
> --
> 1.6.4.1.207.g68ea
>
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
next prev parent reply other threads:[~2009-09-16 13:12 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-15 18:16 [PATCH 0/11] Post merge per-bdi writeback patches v3 Jens Axboe
2009-09-15 18:16 ` [PATCH 01/11] fs: remove bdev->bd_inode_backing_dev_info Jens Axboe
2009-09-16 12:06 ` Jan Kara
2009-09-15 18:16 ` [PATCH 02/11] writeback: get rid of wbc->for_writepages Jens Axboe
2009-09-16 12:07 ` Jan Kara
2009-09-15 18:16 ` [PATCH 03/11] writeback: merely wakeup flusher thread if work allocation fails for WB_SYNC_NONE Jens Axboe
2009-09-16 12:08 ` Jan Kara
2009-09-15 18:16 ` [PATCH 04/11] writeback: make wb_writeback() take an argument structure Jens Axboe
2009-09-16 12:53 ` Jan Kara
2009-09-16 13:06 ` Jens Axboe
2009-09-15 18:16 ` [PATCH 05/11] Assign bdi in super_block Jens Axboe
2009-09-16 12:16 ` Jan Kara
2009-09-16 13:00 ` Jens Axboe
2009-09-15 18:16 ` [PATCH 06/11] writeback: only use bdi_writeback_all() for WB_SYNC_NONE writeout Jens Axboe
2009-09-15 18:16 ` [PATCH 07/11] writeback: use RCU to protect bdi_list Jens Axboe
2009-09-15 18:16 ` [PATCH 08/11] writeback: inline allocation failure handling in bdi_alloc_queue_work() Jens Axboe
2009-09-15 18:16 ` [PATCH 09/11] writeback: separate starting of sync vs opportunistic writeback Jens Axboe
2009-09-16 13:05 ` Jan Kara
2009-09-16 13:07 ` Jens Axboe
2009-09-15 18:16 ` [PATCH 10/11] writeback: splice dirty inode entries to default bdi on bdi_destroy() Jens Axboe
2009-09-16 13:12 ` Jan Kara [this message]
2009-09-16 13:21 ` Jens Axboe
2009-09-16 13:29 ` Jan Kara
2009-09-16 18:31 ` Jens Axboe
2009-09-17 9:33 ` Jan Kara
2009-09-15 18:16 ` [PATCH 11/11] writeback: add comments to bdi_work structure Jens Axboe
2009-09-16 13:15 ` 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=20090916131249.GG26030@duck.suse.cz \
--to=jack@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=chris.mason@oracle.com \
--cc=hch@infradead.org \
--cc=jens.axboe@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=trond.myklebust@fys.uio.no \
--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.