On Sun, 2016-05-08 at 02:01 -0700, h...@infradead.org wrote:
> On Thu, May 05, 2016 at 09:45:07PM +, Verma, Vishal L wrote:
> >
> > I'm not sure I completely understand how this will work? Can you
> > explain
> > a bit? Would we have to export rw_bytes up to layers above the pmem
> > driver? W
On Thu, May 05, 2016 at 09:39:14PM +, Verma, Vishal L wrote:
> How is it any 'less direct'? All it does now is follow the blockdev
> O_DIRECT path. There still isn't any page cache involved..
It's still more overhead than the play DAX I/O path.
On Thu, May 05, 2016 at 09:45:07PM +, Verma, Vishal L wrote:
> I'm not sure I completely understand how this will work? Can you explain
> a bit? Would we have to export rw_bytes up to layers above the pmem
> driver? Where does get_user_pages come in?
A DAX filesystem can directly use the nvdim
On Thu, 2016-05-05 at 08:22 -0700, Christoph Hellwig wrote:
> On Thu, May 05, 2016 at 08:15:32AM -0700, Dan Williams wrote:
> >
> > >
> > > Agreed - makig O_DIRECT less direct than not having it is plain
> > > stupid,
> > > and I somehow missed this initially.
> > Of course I disagree because lik
On Thu, 2016-05-05 at 08:15 -0700, Dan Williams wrote:
> On Thu, May 5, 2016 at 7:24 AM, Christoph Hellwig
> wrote:
> >
> > On Mon, May 02, 2016 at 06:41:51PM +0300, Boaz Harrosh wrote:
> > >
> > > >
> > > > All IO in a dax filesystem used to go through dax_do_io, which
> > > > cannot
> > > > h
On Thu, 2016-05-05 at 07:24 -0700, Christoph Hellwig wrote:
> On Mon, May 02, 2016 at 06:41:51PM +0300, Boaz Harrosh wrote:
> >
> > >
> > > All IO in a dax filesystem used to go through dax_do_io, which
> > > cannot
> > > handle media errors, and thus cannot provide a recovery path that
> > > can
On Thu, May 5, 2016 at 8:22 AM, Christoph Hellwig wrote:
> On Thu, May 05, 2016 at 08:15:32AM -0700, Dan Williams wrote:
>> > Agreed - makig O_DIRECT less direct than not having it is plain stupid,
>> > and I somehow missed this initially.
>>
>> Of course I disagree because like Dave argues in the
On Thu, May 05, 2016 at 08:15:32AM -0700, Dan Williams wrote:
> > Agreed - makig O_DIRECT less direct than not having it is plain stupid,
> > and I somehow missed this initially.
>
> Of course I disagree because like Dave argues in the msync case we
> should do the correct thing first and make it
On Thu, May 5, 2016 at 7:24 AM, Christoph Hellwig wrote:
> On Mon, May 02, 2016 at 06:41:51PM +0300, Boaz Harrosh wrote:
>> > All IO in a dax filesystem used to go through dax_do_io, which cannot
>> > handle media errors, and thus cannot provide a recovery path that can
>> > send a write through t
On Mon, May 02, 2016 at 06:41:51PM +0300, Boaz Harrosh wrote:
> > All IO in a dax filesystem used to go through dax_do_io, which cannot
> > handle media errors, and thus cannot provide a recovery path that can
> > send a write through the driver to clear errors.
> >
> > Add a new iocb flag for DAX
On 05/02/2016 09:48 PM, Dan Williams wrote:
<>
>> 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.
>
Not true!! please see what I wrote "aligned buffered writes"
If there are no read
On Mon, 2016-05-02 at 19:03 +0300, Boaz Harrosh wrote:
> On 05/02/2016 06:51 PM, Vishal Verma wrote:
> >
> > On Mon, 2016-05-02 at 18:41 +0300, Boaz Harrosh wrote:
> > >
> > > On 04/29/2016 12:16 AM, Vishal Verma wrote:
> > > >
> > > >
> > > > All IO in a dax filesystem used to go through dax_d
On Mon, May 2, 2016 at 11:32 AM, Boaz Harrosh 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 wri
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)
>
On Mon, May 2, 2016 at 10:44 AM, Boaz Harrosh wrote:
> On 05/02/2016 07:49 PM, Dan Williams wrote:
>> On Mon, May 2, 2016 at 9:22 AM, Boaz Harrosh wrote:
>>> On 05/02/2016 07:01 PM, Dan Williams wrote:
On Mon, May 2, 2016 at 8:41 AM, Boaz Harrosh wrote:
> On 04/29/2016 12:16 AM, Vishal
On 05/02/2016 07:49 PM, Dan Williams wrote:
> On Mon, May 2, 2016 at 9:22 AM, Boaz Harrosh wrote:
>> On 05/02/2016 07:01 PM, Dan Williams wrote:
>>> On Mon, May 2, 2016 at 8:41 AM, Boaz Harrosh wrote:
On 04/29/2016 12:16 AM, Vishal Verma wrote:
> All IO in a dax filesystem used to go thr
On Mon, May 2, 2016 at 9:22 AM, Boaz Harrosh wrote:
> On 05/02/2016 07:01 PM, Dan Williams wrote:
>> On Mon, May 2, 2016 at 8:41 AM, Boaz Harrosh wrote:
>>> On 04/29/2016 12:16 AM, Vishal Verma wrote:
All IO in a dax filesystem used to go through dax_do_io, which cannot
handle media err
On 05/02/2016 07:01 PM, Dan Williams wrote:
> On Mon, May 2, 2016 at 8:41 AM, Boaz Harrosh wrote:
>> On 04/29/2016 12:16 AM, Vishal Verma wrote:
>>> All IO in a dax filesystem used to go through dax_do_io, which cannot
>>> handle media errors, and thus cannot provide a recovery path that can
>>> s
On 05/02/2016 06:51 PM, Vishal Verma wrote:
> On Mon, 2016-05-02 at 18:41 +0300, Boaz Harrosh wrote:
>> On 04/29/2016 12:16 AM, Vishal Verma wrote:
>>>
>>> All IO in a dax filesystem used to go through dax_do_io, which
>>> cannot
>>> handle media errors, and thus cannot provide a recovery path that
On Mon, May 2, 2016 at 8:41 AM, Boaz Harrosh wrote:
> On 04/29/2016 12:16 AM, Vishal Verma wrote:
>> All IO in a dax filesystem used to go through dax_do_io, which cannot
>> handle media errors, and thus cannot provide a recovery path that can
>> send a write through the driver to clear errors.
>>
On Mon, 2016-05-02 at 07:56 -0700, Christoph Hellwig wrote:
> >
> > index 79defba..97a1f5f 100644
> > --- a/fs/block_dev.c
> > +++ b/fs/block_dev.c
> > @@ -167,12 +167,21 @@ blkdev_direct_IO(struct kiocb *iocb, struct
> > iov_iter *iter, loff_t offset)
> > struct file *file = iocb->ki_filp;
>
On Mon, 2016-05-02 at 18:41 +0300, Boaz Harrosh wrote:
> On 04/29/2016 12:16 AM, Vishal Verma wrote:
> >
> > All IO in a dax filesystem used to go through dax_do_io, which
> > cannot
> > handle media errors, and thus cannot provide a recovery path that
> > can
> > send a write through the driver t
On 04/29/2016 12:16 AM, Vishal Verma wrote:
> All IO in a dax filesystem used to go through dax_do_io, which cannot
> handle media errors, and thus cannot provide a recovery path that can
> send a write through the driver to clear errors.
>
> Add a new iocb flag for DAX, and set it only for DAX mo
> index 79defba..97a1f5f 100644
> --- a/fs/block_dev.c
> +++ b/fs/block_dev.c
> @@ -167,12 +167,21 @@ blkdev_direct_IO(struct kiocb *iocb, struct iov_iter
> *iter, loff_t offset)
> struct file *file = iocb->ki_filp;
> struct inode *inode = bdev_file_inode(file);
>
> - if (IS_DAX(
All IO in a dax filesystem used to go through dax_do_io, which cannot
handle media errors, and thus cannot provide a recovery path that can
send a write through the driver to clear errors.
Add a new iocb flag for DAX, and set it only for DAX mounts. In the IO
path for DAX filesystems, use the same
25 matches
Mail list logo
