NeilBrown <neilb@xxxxxxx> writes: > Hi Andrew (and others) > I wonder if you would review the following for me and comment. > > Thanks, > NeilBrown > > > > From e7f75c2a757108cdd83ce8c808a16bf27686c95f Mon Sep 17 00:00:00 2001 > From: NeilBrown <neilb@xxxxxxx> > Date: Thu, 17 Feb 2011 16:37:30 +1100 > Subject: [PATCH] Fix over-zealous flush_disk when changing device size. > > There are two cases when we call flush_disk. > In one, the device has disappeared (check_disk_change) so any > data will hold becomes irrelevant. > In the oter, the device has changed size (check_disk_size_change) > so data we hold may be irrelevant. > > In both cases it makes sense to discard any 'clean' buffers, > so they will be read back from the device if needed. > > In the former case it makes sense to discard 'dirty' buffers > as there will never be anywhere safe to write the data. In the > second case it *does*not* make sense to discard dirty buffers > as that will lead to file system corruption when you simply enlarge > the containing devices. > > flush_disk calls __invalidate_devices. > __invalidate_device calls both invalidate_inodes and invalidate_bdev. > > invalidate_inodes *does* discard I_DIRTY inodes and this does lead > to fs corruption. > > invalidate_bev *does*not* discard dirty pages, but I don't really care > about that at present. > > So this patch adds a flag to __invalidate_device (calling it > __invalidate_device2) to indicate whether dirty buffers should be > killed, and this is passed to invalidate_inodes which can choose to > skip dirty inodes. > > flusk_disk then passes true from check_disk_change and false from > check_disk_size_change. > > dm avoids tripping over this problem by calling i_size_write directly > rathher than using check_disk_size_change. > > md does use check_disk_size_change and so is affected. > > This regression was introduced by commit 608aeef17a > which causes check_disk_size_change to call > flush_disk. This makes sense to me. Nice write-up, Neil. Acked-by: Jeff Moyer <jmoyer@xxxxxxxxxx> -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
