xfs
[Top] [All Lists]

Re: [PATCH v2 5/5] dax: handle media errors in dax_do_io

To: "Verma, Vishal L" <vishal.l.verma@xxxxxxxxx>
Subject: Re: [PATCH v2 5/5] dax: handle media errors in dax_do_io
From: "hch@xxxxxxxxxxxxx" <hch@xxxxxxxxxxxxx>
Date: Tue, 26 Apr 2016 01:33:32 -0700
Cc: "hch@xxxxxxxxxxxxx" <hch@xxxxxxxxxxxxx>, "Wilcox, Matthew R" <matthew.r.wilcox@xxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, "linux-block@xxxxxxxxxxxxxxx" <linux-block@xxxxxxxxxxxxxxx>, "xfs@xxxxxxxxxxx" <xfs@xxxxxxxxxxx>, "linux-nvdimm@xxxxxxxxxxx" <linux-nvdimm@xxxxxxxxxxx>, "jmoyer@xxxxxxxxxx" <jmoyer@xxxxxxxxxx>, "linux-mm@xxxxxxxxx" <linux-mm@xxxxxxxxx>, "viro@xxxxxxxxxxxxxxxxxx" <viro@xxxxxxxxxxxxxxxxxx>, "axboe@xxxxxx" <axboe@xxxxxx>, "akpm@xxxxxxxxxxxxxxxxxxxx" <akpm@xxxxxxxxxxxxxxxxxxxx>, "linux-fsdevel@xxxxxxxxxxxxxxx" <linux-fsdevel@xxxxxxxxxxxxxxx>, "linux-ext4@xxxxxxxxxxxxxxx" <linux-ext4@xxxxxxxxxxxxxxx>, "david@xxxxxxxxxxxxx" <david@xxxxxxxxxxxxx>, "jack@xxxxxxx" <jack@xxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <1461604476.3106.12.camel@xxxxxxxxx>
References: <1459303190-20072-1-git-send-email-vishal.l.verma@xxxxxxxxx> <1459303190-20072-6-git-send-email-vishal.l.verma@xxxxxxxxx> <x49twj26edj.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20160420205923.GA24797@xxxxxxxxxxxxx> <1461434916.3695.7.camel@xxxxxxxxx> <20160425083114.GA27556@xxxxxxxxxxxxx> <1461604476.3106.12.camel@xxxxxxxxx>
User-agent: Mutt/1.5.24 (2015-08-30)
On Mon, Apr 25, 2016 at 05:14:36PM +0000, Verma, Vishal L wrote:
> - Application hits EIO doing dax_IO or load/store io
> 
> - It checks badblocks and discovers it's files have lost data
> 
> - It write()s those sectors (possibly converted to file offsets using
> fiemap)
> ?? ?? * This triggers the fallback path, but if the application is doing
> this level of recovery, it will know the sector is bad, and write the
> entire sector

This sounds like a mess.

> I think if we want to keep allowing arbitrary alignments for the
> dax_do_io path, we'd need:
> 1. To represent badblocks at a finer granularity (likely cache lines)
> 2. To allow the driver to do IO to a *block device* at sub-sector
> granularity

It's not a block device if it supports DAX.  It's byte addressable
memory masquerading as a block device.

<Prev in Thread] Current Thread [Next in Thread>