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);
next prev 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).