Re: [Lsf-pc] [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-24 Thread Vishal Verma
On 01/24, Jan Kara wrote: > On Fri 20-01-17 07:42:09, Dan Williams wrote: > > On Fri, Jan 20, 2017 at 1:47 AM, Jan Kara wrote: > > > On Thu 19-01-17 14:17:19, Vishal Verma wrote: > > >> On 01/18, Jan Kara wrote: > > >> > On Tue 17-01-17 15:37:05, Vishal Verma wrote: > > >> > 2) PMEM

Re: [Lsf-pc] [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-23 Thread Jan Kara
On Fri 20-01-17 07:42:09, Dan Williams wrote: > On Fri, Jan 20, 2017 at 1:47 AM, Jan Kara wrote: > > On Thu 19-01-17 14:17:19, Vishal Verma wrote: > >> On 01/18, Jan Kara wrote: > >> > On Tue 17-01-17 15:37:05, Vishal Verma wrote: > >> > 2) PMEM is exposed for DAX aware filesystem.

Re: [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-20 Thread Kani, Toshimitsu
On Fri, 2017-01-20 at 18:24 +0900, Yasunori Goto wrote: : > > > > Like mentioned before, this discussion is more about presentation > > of errors in a known consumable format, rather than recovering from > > errors. While recovering from errors is interesting, we already > > have layers like

Re: [Lsf-pc] [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-20 Thread Dan Williams
On Fri, Jan 20, 2017 at 1:47 AM, Jan Kara wrote: > On Thu 19-01-17 14:17:19, Vishal Verma wrote: >> On 01/18, Jan Kara wrote: >> > On Tue 17-01-17 15:37:05, Vishal Verma wrote: >> > 2) PMEM is exposed for DAX aware filesystem. This seems to be what you are >> > mostly interested in.

Re: [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-20 Thread Yasunori Goto
Hello, Virshal-san. First of all, your discussion is quite interesting for me. Thanks. > > > > If DUE does happen and is flagged to the file system via MCE (somehow...), > > and the fs finds that the error corrupts its allocated data page, or > > metadata, now if the fs wants to recover its

Re: [Lsf-pc] [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-20 Thread Jan Kara
On Thu 19-01-17 14:17:19, Vishal Verma wrote: > On 01/18, Jan Kara wrote: > > On Tue 17-01-17 15:37:05, Vishal Verma wrote: > > 2) PMEM is exposed for DAX aware filesystem. This seems to be what you are > > mostly interested in. We could possibly do something more efficient than > > what NVDIMM

Re: [Lsf-pc] [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-20 Thread Jan Kara
On Thu 19-01-17 11:03:12, Dan Williams wrote: > On Thu, Jan 19, 2017 at 10:59 AM, Vishal Verma > wrote: > > On 01/19, Jan Kara wrote: > >> On Wed 18-01-17 21:56:58, Verma, Vishal L wrote: > >> > On Wed, 2017-01-18 at 13:32 -0800, Dan Williams wrote: > >> > > On Wed, Jan

Re: [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-19 Thread Verma, Vishal L
shal.l.verma@inte > > > l.com> wrote: > > > > On 01/16, Darrick J. Wong wrote: > > > > > On Fri, Jan 13, 2017 at 05:49:10PM -0700, Vishal Verma wrote: > > > > > > On 01/14, Slava Dubeyko wrote: > > > > > > >

Re: [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-19 Thread Vishal Verma
..@intel.com> > > wrote: > > >>> On 01/16, Darrick J. Wong wrote: > > >>>> On Fri, Jan 13, 2017 at 05:49:10PM -0700, Vishal Verma wrote: > > >>>>> On 01/14, Slava Dubeyko wrote: > > >>>>>> > > >

Re: [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-19 Thread Verma, Vishal L
On Tue, 2017-01-17 at 17:58 -0800, Andiry Xu wrote: > On Tue, Jan 17, 2017 at 3:51 PM, Vishal Verma m> wrote: > > On 01/17, Andiry Xu wrote: > > > > > > > > > > > > > > > > The pmem_do_bvec() read logic is like this: > > > > > > > > > > pmem_do_bvec() > > > > >

Re: [Lsf-pc] [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-19 Thread Vishal Verma
On 01/18, Jan Kara wrote: > On Tue 17-01-17 15:37:05, Vishal Verma wrote: > > I do mean that in the filesystem, for every IO, the badblocks will be > > checked. Currently, the pmem driver does this, and the hope is that the > > filesystem can do a better job at it. The driver unconditionally

Re: [Lsf-pc] [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-19 Thread Jeff Moyer
Hi, Slava, Slava Dubeyko writes: >>The data is lost, that's why you're getting an ECC. It's tantamount >>to -EIO for a disk block access. > > I see the three possible cases here: > (1) bad block has been discovered (no remap, no recovering) -> data is >> lost; -EIO

Re: [Lsf-pc] [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-19 Thread Vishal Verma
On 01/19, Jan Kara wrote: > On Wed 18-01-17 21:56:58, Verma, Vishal L wrote: > > On Wed, 2017-01-18 at 13:32 -0800, Dan Williams wrote: > > > On Wed, Jan 18, 2017 at 1:02 PM, Darrick J. Wong > > > wrote: > > > > On Wed, Jan 18, 2017 at 03:39:17PM -0500, Jeff Moyer wrote:

Re: [Lsf-pc] [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-19 Thread Dan Williams
On Thu, Jan 19, 2017 at 10:59 AM, Vishal Verma wrote: > On 01/19, Jan Kara wrote: >> On Wed 18-01-17 21:56:58, Verma, Vishal L wrote: >> > On Wed, 2017-01-18 at 13:32 -0800, Dan Williams wrote: >> > > On Wed, Jan 18, 2017 at 1:02 PM, Darrick J. Wong >> > >

Re: [Lsf-pc] [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-18 Thread Darrick J. Wong
On Wed, Jan 18, 2017 at 03:39:17PM -0500, Jeff Moyer wrote: > Jan Kara writes: > > > On Tue 17-01-17 15:14:21, Vishal Verma wrote: > >> Your note on the online repair does raise another tangentially related > >> topic. Currently, if there are badblocks, writes via the bio

RE: [Lsf-pc] [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-18 Thread Slava Dubeyko
Viacheslav Dubeyko <sl...@dubeyko.com>; Linux FS Devel <linux-fsde...@vger.kernel.org>; lsf...@lists.linux-foundation.org Subject: Re: [Lsf-pc] [LSF/MM TOPIC] Badblocks checking/representation in filesystems >>> Well, the situation with NVM is more like with DRAM AFAIU. It is

Re: [Lsf-pc] [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-18 Thread Jeff Moyer
Jan Kara writes: > On Tue 17-01-17 15:14:21, Vishal Verma wrote: >> Your note on the online repair does raise another tangentially related >> topic. Currently, if there are badblocks, writes via the bio submission >> path will clear the error (if the hardware is able to remap the

Re: [Lsf-pc] [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-18 Thread Jeff Moyer
Slava Dubeyko writes: >> Well, the situation with NVM is more like with DRAM AFAIU. It is quite >> reliable >> but given the size the probability *some* cell has degraded is quite high. >> And similar to DRAM you'll get MCE (Machine Check Exception) when you try >>

Re: [Lsf-pc] [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-18 Thread Jan Kara
On Tue 17-01-17 15:14:21, Vishal Verma wrote: > Your note on the online repair does raise another tangentially related > topic. Currently, if there are badblocks, writes via the bio submission > path will clear the error (if the hardware is able to remap the bad > locations). However, if the

Re: [Lsf-pc] [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-18 Thread Jan Kara
On Tue 17-01-17 15:37:05, Vishal Verma wrote: > I do mean that in the filesystem, for every IO, the badblocks will be > checked. Currently, the pmem driver does this, and the hope is that the > filesystem can do a better job at it. The driver unconditionally checks > every IO for badblocks on the

Re: [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-17 Thread Andiry Xu
ong wrote: >>>> On Fri, Jan 13, 2017 at 05:49:10PM -0700, Vishal Verma wrote: >>>>> On 01/14, Slava Dubeyko wrote: >>>>>> >>>>>> ---- Original Message >>>>>> Subject: [LSF/MM TOPIC] Badblocks checking/representatio

Re: [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-17 Thread Andiry Xu
On Tue, Jan 17, 2017 at 3:51 PM, Vishal Verma wrote: > On 01/17, Andiry Xu wrote: > > > >> >> >> >> The pmem_do_bvec() read logic is like this: >> >> >> >> pmem_do_bvec() >> >> if (is_bad_pmem()) >> >> return -EIO; >> >> else >> >>

Re: [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-17 Thread Andreas Dilger
gt;>>> On 01/14, Slava Dubeyko wrote: >>>>> >>>>> ---- Original Message >>>>> Subject: [LSF/MM TOPIC] Badblocks checking/representation in filesystems >>>>> Sent: Jan 13, 2017 1:40 PM >>>>> From: "Verma, Vish

Re: [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-17 Thread Vishal Verma
On 01/17, Andiry Xu wrote: > >> > >> The pmem_do_bvec() read logic is like this: > >> > >> pmem_do_bvec() > >> if (is_bad_pmem()) > >> return -EIO; > >> else > >> memcpy_from_pmem(); > >> > >> Note memcpy_from_pmem() is calling memcpy_mcsafe(). Does this imply > >> that

RE: [Lsf-pc] [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-17 Thread Slava Dubeyko
lsf...@lists.linux-foundation.org; Viacheslav Dubeyko <sl...@dubeyko.com>; linux-nvd...@lists.01.org Subject: Re: [Lsf-pc] [LSF/MM TOPIC] Badblocks checking/representation in filesystems > > > We don't have direct physical access to the device's address space, > > > in the

Re: [Lsf-pc] [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-17 Thread Vishal Verma
@wdc.com> > > Cc: lsf...@lists.linux-foundation.org; linux-nvd...@lists.01.org; > > linux-block@vger.kernel.org; Linux FS Devel > > <linux-fsde...@vger.kernel.org>; Viacheslav Dubeyko <sl...@dubeyko.com> > > Subject: Re: [LSF/MM TOPIC] Badblocks checking/representati

Re: [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-17 Thread Vishal Verma
On 01/16, Darrick J. Wong wrote: > On Fri, Jan 13, 2017 at 05:49:10PM -0700, Vishal Verma wrote: > > On 01/14, Slava Dubeyko wrote: > > > > > > Original Message ---- > > > Subject: [LSF/MM TOPIC] Badblocks checking/representation in filesystems > &g

RE: [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-15 Thread Slava Dubeyko
inux-fsde...@vger.kernel.org>; Viacheslav Dubeyko <sl...@dubeyko.com> Subject: Re: [LSF/MM TOPIC] Badblocks checking/representation in filesystems > We don't have direct physical access to the device's address space, in the > sense > the device is still free to perform remapping of

Re: [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-13 Thread Vishal Verma
On 01/14, Slava Dubeyko wrote: > > Original Message > Subject: [LSF/MM TOPIC] Badblocks checking/representation in filesystems > Sent: Jan 13, 2017 1:40 PM > From: "Verma, Vishal L" <vishal.l.ve...@intel.com> > To: lsf...@lists.linux-foundation.org >

RE: [LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-13 Thread Slava Dubeyko
Original Message Subject: [LSF/MM TOPIC] Badblocks checking/representation in filesystems Sent: Jan 13, 2017 1:40 PM From: "Verma, Vishal L" <vishal.l.ve...@intel.com> To: lsf...@lists.linux-foundation.org Cc: linux-nvd...@lists.01.org, linux-block@vger.kernel.

[LSF/MM TOPIC] Badblocks checking/representation in filesystems

2017-01-13 Thread Verma, Vishal L
The current implementation of badblocks, where we consult the badblocks list for every IO in the block driver works, and is a last option failsafe, but from a user perspective, it isn't the easiest interface to work with. A while back, Dave Chinner had suggested a move towards smarter handling,