linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Jens Axboe <axboe@kernel.dk>
Cc: Christoph Hellwig <hch@infradead.org>,
	linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
	ocfs2-devel@oss.oracle.com, Evgeniy Dushistov <dushistov@mail.ru>,
	linux-ntfs-dev@lists.sourceforge.net, Jan Kara <jack@suse.cz>
Subject: [PATCH 6/6] fs: Remove unmap_underlying_metadata
Date: Fri,  4 Nov 2016 18:08:16 +0100	[thread overview]
Message-ID: <1478279296-6575-7-git-send-email-jack@suse.cz> (raw)
In-Reply-To: <1478279296-6575-1-git-send-email-jack@suse.cz>

Nobody is using this function anymore. Remove it.

Signed-off-by: Jan Kara <jack@suse.cz>
---
 fs/buffer.c                 | 32 --------------------------------
 include/linux/buffer_head.h |  1 -
 2 files changed, 33 deletions(-)

diff --git a/fs/buffer.c b/fs/buffer.c
index f96c079e181d..6d6680c8d306 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -1605,38 +1605,6 @@ void create_empty_buffers(struct page *page,
 }
 EXPORT_SYMBOL(create_empty_buffers);
 
-/*
- * We are taking a block for data and we don't want any output from any
- * buffer-cache aliases starting from return from that function and
- * until the moment when something will explicitly mark the buffer
- * dirty (hopefully that will not happen until we will free that block ;-)
- * We don't even need to mark it not-uptodate - nobody can expect
- * anything from a newly allocated buffer anyway. We used to used
- * unmap_buffer() for such invalidation, but that was wrong. We definitely
- * don't want to mark the alias unmapped, for example - it would confuse
- * anyone who might pick it with bread() afterwards...
- *
- * Also..  Note that bforget() doesn't lock the buffer.  So there can
- * be writeout I/O going on against recently-freed buffers.  We don't
- * wait on that I/O in bforget() - it's more efficient to wait on the I/O
- * only if we really need to.  That happens here.
- */
-void unmap_underlying_metadata(struct block_device *bdev, sector_t block)
-{
-	struct buffer_head *old_bh;
-
-	might_sleep();
-
-	old_bh = __find_get_block_slow(bdev, block);
-	if (old_bh) {
-		clear_buffer_dirty(old_bh);
-		wait_on_buffer(old_bh);
-		clear_buffer_req(old_bh);
-		__brelse(old_bh);
-	}
-}
-EXPORT_SYMBOL(unmap_underlying_metadata);

  parent reply	other threads:[~2016-11-04 17:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-04 17:08 [PATCH 0/6 v2] fs: Provide function to unmap metadata for a range of blocks Jan Kara
2016-11-04 17:08 ` [PATCH 1/6] " Jan Kara
2016-11-04 17:08 ` [PATCH 2/6] direct-io: Use clean_bdev_aliases() instead of handmade iteration Jan Kara
2016-11-04 17:08 ` [PATCH 3/6] ext4: Use clean_bdev_aliases() instead of iteration Jan Kara
2016-11-07  2:40   ` [lkp] [ext4] adad5aa544: fio.write_bw_MBps +4074.4% improvement kernel test robot
2016-11-04 17:08 ` [PATCH 4/6] ext2: Use clean_bdev_aliases() instead of iteration Jan Kara
2016-11-04 17:08 ` [PATCH 5/6] fs: Add helper to clean bdev aliases under a bh and use it Jan Kara
2016-11-04 17:08 ` Jan Kara [this message]
2016-11-04 20:32 ` [PATCH 0/6 v2] fs: Provide function to unmap metadata for a range of blocks Jens Axboe

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=1478279296-6575-7-git-send-email-jack@suse.cz \
    --to=jack@suse.cz \
    --cc=axboe@kernel.dk \
    --cc=dushistov@mail.ru \
    --cc=hch@infradead.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-ntfs-dev@lists.sourceforge.net \
    --cc=ocfs2-devel@oss.oracle.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).