Messages in this thread | | | Date | Thu, 4 Dec 2008 23:15:51 +0100 | From | Andi Kleen <> | Subject | Re: Device loses barrier support (was: Fixed patch for simple barriers.) |
| |
> If you are pushing what you are pushing --- barriers allowing to return > EOPNOTSUPP anytime --- then asynchronous barrier submits can no longer be > used, because by the time EOPNOTSUPP is detected, the filesystem is > already corrupted.
Chris Mason pointed out that this can actually already happen. From a quick review this can happen in MD raid1 at least (their barriers_work flag is pretty similar to the DM implementation I did). So everyone has to handle this already anyways.
> I'm wondering, where in fsync() does Linux wait for hardware disk cache to > be flushed? Isn't there a bug that fsync() will return before the cache is > flushed? I couldn't really find it. The last thing do_fsync calls is > filemap_fdatawait and it doesn't do cache flush (blkdev_issue_flush).
At least in fsync() on journaling fs the metadata update should push it.
-Andi
-- ak@linux.intel.com
| |