This function is only called from write path which flushes pages to disk, actually, pages' state have been set right at time when write_end() is called. Why did we handle pages' state in this function? On Tue, Apr 26, 2011 at 6:40 AM, Andreas Dilger <adilger@xxxxxxxxx> wrote: > On 2011-04-25, at 2:23 PM, Curt Wohlgemuth wrote: >> In the bio completion routine, we should not be setting >> PageUptodate at all -- it's set at sys_write() time, and is >> unaffected by success/failure of the write to disk. >> >> This can cause a page corruption bug when >> >> block size < page size >> >> @@ -203,46 +203,29 @@ static void ext4_end_bio(struct bio *bio, int error) >> - /* >> - * If this is a partial write which happened to make >> - * all buffers uptodate then we can optimize away a >> - * bogus readpage() for the next read(). Here we >> - * 'discover' whether the page went uptodate as a >> - * result of this (potentially partial) write. >> - */ >> - if (!partial_write) >> - SetPageUptodate(page); >> - > > I think this is the important part of the code - if there is a read-after-write for a file that was written in "blocksize" units (blocksize < pagesize), does the page get set uptodate when all of the blocks have been written and/or the writing is at EOF? Otherwise, a read-after-write will always cause data to be fetched from disk needlessly, even though the uptodate information is already in cache. > > Cheers, Andreas > > > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Best Wishes Yongqiang Yang -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
