aboutsummaryrefslogtreecommitdiffstats
path: root/fs/buffer.c
diff options
context:
space:
mode:
authorAl Viro <viro@zeniv.linux.org.uk>2011-09-16 02:31:11 -0400
committerAl Viro <viro@zeniv.linux.org.uk>2012-01-03 22:54:07 -0500
commitff01bb4832651c6d25ac509a06a10fcbd75c461c (patch)
treebbfdebd317db97d346df78293566f36e883b1be9 /fs/buffer.c
parent94ea4158f1733e3b10cef067d535f504866e0c41 (diff)
fs: move code out of buffer.c
Move invalidate_bdev, block_sync_page into fs/block_dev.c. Export kill_bdev as well, so brd doesn't have to open code it. Reduce buffer_head.h requirement accordingly. Removed a rather large comment from invalidate_bdev, as it looked a bit obsolete to bother moving. The small comment replacing it says enough. Signed-off-by: Nick Piggin <npiggin@suse.de> Cc: Al Viro <viro@ZenIV.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'fs/buffer.c')
-rw-r--r--fs/buffer.c50
1 files changed, 0 insertions, 50 deletions
diff --git a/fs/buffer.c b/fs/buffer.c
index 19d8eb7fdc81..1a30db77af32 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -41,7 +41,6 @@
41#include <linux/bitops.h> 41#include <linux/bitops.h>
42#include <linux/mpage.h> 42#include <linux/mpage.h>
43#include <linux/bit_spinlock.h> 43#include <linux/bit_spinlock.h>
44#include <linux/cleancache.h>
45 44
46static int fsync_buffers_list(spinlock_t *lock, struct list_head *list); 45static int fsync_buffers_list(spinlock_t *lock, struct list_head *list);
47 46
@@ -231,55 +230,6 @@ out:
231 return ret; 230 return ret;
232} 231}
233 232
234/* If invalidate_buffers() will trash dirty buffers, it means some kind
235 of fs corruption is going on. Trashing dirty data always imply losing
236 information that was supposed to be just stored on the physical layer
237 by the user.
238
239 Thus invalidate_buffers in general usage is not allwowed to trash
240 dirty buffers. For example ioctl(FLSBLKBUF) expects dirty data to
241 be preserved. These buffers are simply skipped.
242
243 We also skip buffers which are still in use. For example this can
244 happen if a userspace program is reading the block device.
245
246 NOTE: In the case where the user removed a removable-media-disk even if
247 there's still dirty data not synced on disk (due a bug in the device driver
248 or due an error of the user), by not destroying the dirty buffers we could
249 generate corruption also on the next media inserted, thus a parameter is
250 necessary to handle this case in the most safe way possible (trying
251 to not corrupt also the new disk inserted with the data belonging to
252 the old now corrupted disk). Also for the ramdisk the natural thing
253 to do in order to release the ramdisk memory is to destroy dirty buffers.
254
255 These are two special cases. Normal usage imply the device driver
256 to issue a sync on the device (without waiting I/O completion) and
257 then an invalidate_buffers call that doesn't trash dirty buffers.
258
259 For handling cache coherency with the blkdev pagecache the 'update' case
260 is been introduced. It is needed to re-read from disk any pinned
261 buffer. NOTE: re-reading from disk is destructive so we can do it only
262 when we assume nobody is changing the buffercache under our I/O and when
263 we think the disk contains more recent information than the buffercache.
264 The update == 1 pass marks the buffers we need to update, the update == 2
265 pass does the actual I/O. */
266void invalidate_bdev(struct block_device *bdev)
267{
268 struct address_space *mapping = bdev->bd_inode->i_mapping;
269
270 if (mapping->nrpages == 0)
271 return;
272
273 invalidate_bh_lrus();
274 lru_add_drain_all(); /* make sure all lru add caches are flushed */
275 invalidate_mapping_pages(mapping, 0, -1);
276 /* 99% of the time, we don't need to flush the cleancache on the bdev.
277 * But, for the strange corners, lets be cautious
278 */
279 cleancache_flush_inode(mapping);
280}
281EXPORT_SYMBOL(invalidate_bdev);
282
283/* 233/*
284 * Kick the writeback threads then try to free up some ZONE_NORMAL memory. 234 * Kick the writeback threads then try to free up some ZONE_NORMAL memory.
285 */ 235 */