On Jul 18, 2014, at 1:49 PM, Sougata Santra wrote: > On Fri, 2014-07-18 at 13:01 +0400, Vyacheslav Dubeyko wrote: >> On Fri, 2014-07-18 at 11:35 +0300, Sougata Santra wrote: >> >> [snip] >>> 2) Also, there was a error in error propagation. It it also fixed in >>> this patch. >>> -->snip<-- >>> if (!error) >>> error2 = error; >>> -->snap<-- >>> >>> 3) The disk is only flushed if there was no error. Previously it was >>> always flushed without checking the error. >> >> So, do you mean that filemap_write_and_wait() and hfsplus_submit_bio() >> doesn't request writing on a volume? > Yes it did, but it wrote in the page-cache ?. The hfsplus_submit_bio() makes bio allocation via bio_alloc() and, then, send request on write into elevator queue by means of submit_bio_wait(). Moreover, submit_bio_wait() submits a bio, and wait until it completes. It means that we have changed block on volume after returning from hfsplus_submit_bio(). The filemap_write_and_wait() calls do_writepages() finally. It calls mapping->a_ops->writepages(). So, it means that do_writepages() calls hfsplus_writepages(). As a result, finally, requests on write are placed in elevator queue. And, again, dirty pages of inode->i_mapping (page cache) will be on volume after returning from filemap_write_and_wait(). This is my understanding of hfsplus_sync_fs() method's logic. Please, correct me if I am wrong. So, if you try to prevent from blkdev_issue_flush() then it doesn't mean that you prevent from writing special files and volume header on volume. I suppose that logic of writing in any case was special policy. Because fsck utility can help to us in some bad situations. This is my understanding of this method's logic. Thanks, Vyacheslav Dubeyko. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
