Andrew Patterson <andrew.patterson@xxxxxx> writes: > Call flush_disk() after detecting an online resize. > > We call flush_disk() to make sure the buffer cache for the disk is > flushed after a disk resize. There are two resize cases, growing and > shrinking. Given that users can shrink/then grow a disk before > revalidate_disk() is called, we treat the grow case identically to > shrinking. We need to flush the buffer cache after an online shrink > because, as James Bottomley puts it, > > The two use cases for shrinking I can see are > > 1. planned: the fs is already shrunk to within the new boundaries > and all data is relocated, so invalidate is fine (any dirty > buffers that might exist in the shrunk region are there only > because they were relocated but not yet written to their > original location). > 2. unplanned: In this case, the fs is probably toast, so whether > we invalidate or not isn't going to make a whole lot of > difference; it's still going to try to read or write from > sectors beyond the new size and get I/O errors. > > Immediately invalidating shrunk disks will cause errors for outstanding > I/Os for reads/write beyond the new end of the disk to be generated > earlier then if we waited for the normal buffer cache operation. It also > removes a potential security hole where we might keep old data around > from beyond the end of the shrunk disk if the disk was not invalidated. > > Signed-off-by: Andrew Patterson <andrew.patterson@xxxxxx> Reviewed-by: Jeff Moyer <jmoyer@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
