On Tue, 2016-03-29 at 23:34 -0700, Christoph Hellwig wrote:
> Hi Vishal,
>
> still NAK to calling the direct I/O code directly from the dax code.
Hm, I thought this was what you meant -- do the fallback/retry attempts
at the callers of dax_do_io instead of the new dax wrapper function..
Did I
On Tue, 2016-03-29 at 23:34 -0700, Christoph Hellwig wrote:
> Hi Vishal,
>
> still NAK to calling the direct I/O code directly from the dax code.
Hm, I thought this was what you meant -- do the fallback/retry attempts
at the callers of dax_do_io instead of the new dax wrapper function..
Did I
Hi Vishal,
still NAK to calling the direct I/O code directly from the dax code.
Hi Vishal,
still NAK to calling the direct I/O code directly from the dax code.
Hi Vishal,
[auto build test WARNING on linux-nvdimm/libnvdimm-for-next]
[also build test WARNING on v4.6-rc1 next-20160329]
[cannot apply to xfs/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
Hi Vishal,
[auto build test WARNING on linux-nvdimm/libnvdimm-for-next]
[also build test WARNING on v4.6-rc1 next-20160329]
[cannot apply to xfs/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
dax_do_io (called for read() or write() for a dax file system) may fail
in the presence of bad blocks or media errors. Since we expect that a
write should clear media errors on nvdimms, make dax_do_io fall back to
the direct_IO path, which will send down a bio to the driver, which can
then attempt
dax_do_io (called for read() or write() for a dax file system) may fail
in the presence of bad blocks or media errors. Since we expect that a
write should clear media errors on nvdimms, make dax_do_io fall back to
the direct_IO path, which will send down a bio to the driver, which can
then attempt
101 - 108 of 108 matches
Mail list logo