Hi! > Also, the changelog needs some work, methinks. > > /** > * blkdev_issue_flush - queue a flush > * @bdev: blockdev to issue flush for > * @error_sector: error sector > * > * Description: > * Issue a flush for the block device in question. Caller can supply > * room for storing the error offset in case of a flush error, if they > * wish to. Caller must run wait_for_completion() on its own. > */ > > So afaict the change you've made is incomplete. We'll queue a > writeback command to the disk but we won't wait for it to be sent down > the wire. Nor do we wait for the command to complete at the device > end. So it can still be a looong time (seconds!) before the data which > the user thinks is on disk really is safe. > > Yes? > > If so, this design decision should be described in the changelog, and > justified. Actually, doing this in the comment over > ext3_blkdev_issue_flush() would be good. Actually, if sync() and fsync() do not work, it probably needs more than a comment in changelog. Like comment in documentation, in big bold letters. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
