On Mon, May 2, 2016 at 11:32 AM, Boaz Harrosh <boaz@xxxxxxxxxxxxx> wrote: > On 05/02/2016 09:10 PM, Dan Williams wrote: > <> >> >> The semantic I am talking about preserving is: >> >> buffered / unaligned write of a bad sector => -EIO on reading into the >> page cache >> > > What about aligned buffered write? like write 0-to-eof > This still broken? (and is what restore apps do) > >> ...and that the only guaranteed way to clear an error (assuming the >> block device supports it) is an O_DIRECT write. >> > > Sure fixing dax_do_io will guaranty that. > > <> >> I still think we're talking past each other on this point. > > Yes we are! > >> This patch >> set is not overloading error semantics, it's fixing the error handling >> problem that was introduced in this commit: >> >> d475c6346a38 dax,ext2: replace XIP read and write with DAX I/O >> >> ...where we started overloading O_DIRECT and dax_do_io() semantics. >> > > But above does not fix them does it? it just completely NULLs DAX for > O_DIRECT which is a great pity, why did we do all this work in the first > place. This is hyperbole. We don't impact "all the work" we did for the mmap I/O case and the acceleration of the non-direct-I/O case. > And then it keeps broken the aligned buffered writes, which are still > broken after this set. ...identical to the current situation with a traditional disk. > I have by now read the v2 patches. And I think you guys did not yet try > the proper fix for dax_do_io. I think you need to go deeper into the loops > and selectively call bdev_* when error on a specific page copy. No need to > go through direct_IO path at all. We still reach a point where the minimum granularity of bdev_direct_access() is larger than a sector, so you end up still needing to have the application understand how to send a properly aligned I/O. The semantics of how to send a properly aligned direct-I/O are already well understood, so we simply reuse that path. > Do you need that I send you a patch to demonstrate what I mean? I remain skeptical of what you are proposing, but yes, a patch has a better chance to move the discussion forward. -- 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
