[lkml]   [2008]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 6/6] Call flush_disk() after detecting an online resize.
    Andrew Patterson <> 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 <>
    Reviewed-by: Jeff Moyer <>

     \ /
      Last update: 2008-09-03 20:33    [W:0.029 / U:3.208 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site