Messages in this thread | | | From | Jeff Moyer <> | Subject | Re: [PATCH 6/6] Call flush_disk() after detecting an online resize. | Date | Wed, 03 Sep 2008 14:20:11 -0400 |
| |
Andrew Patterson <andrew.patterson@hp.com> 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@hp.com> Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
| |