public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Vishal Verma <vishal.l.verma@intel.com>
To: linux-nvdimm@lists.01.org, xfs@oss.sgi.com
Cc: Jan Kara <jack@suse.cz>, "Darrick J. Wong" <darrick.wong@oracle.com>
Subject: Re: [RFC PATCH 0/2] Initial support for badblock checking in xfs
Date: Mon, 20 Jun 2016 12:48:27 -0600	[thread overview]
Message-ID: <20160620184812.GA21878@omniknight.lm.intel.com> (raw)
In-Reply-To: <1466125419-17736-1-git-send-email-vishal.l.verma@intel.com>

On 06/16, Vishal Verma wrote:
> These are early/RFC patches to add badblock support in xfs.
> 
> Patch 1 should be relatively straightforward - it adds a notifier chain
> to badblocks that filesystems can register with.
> 
> Patch 2 is the beginnings of xfs support. So far, I have the notifier
> registration and building the initial badblock list happening in
> xfs_mountfs. The next steps (and I may need some help with this as I'm
> no (x)fs developer :)) are to add this badblocks info to the reverse
> mapping tree, and then to check for it before accessing the media.
> 
> Right now, this just prints the sector numbers/counts/{added, removed}
> to the kernel log, for both the initial list, and subsequent notifier
> hits.
> 
> While I've tested this with a fake pmem device using libnvdimm's
> nfit_test framework, it should also work using badblock injection with
> any block device:
> 
> # mkfs.xfs -f /dev/<device>
> # echo 122 1 > /sys/block/<device>/badblocks
> # echo 124 1 > /sys/block/<device>/badblocks
> # mount -t xfs /dev/<device> /mnt
> ... in log:
> [  +8.803776] XFS (pmem7): Mounting V4 Filesystem
> [  +0.009633] XFS (pmem7): Ending clean mount
> [  +0.001655] XFS (pmem7): got badblocks: sector 122, count 1
> [  +0.002018] XFS (pmem7): got badblocks: sector 124, count 1
> 
> # echo 132 5 | > /sys/block/<device>/badblocks
> [Jun16 18:56] XFS (pmem7): xfs badblock added sector 132 (count 5)
> 
> This is all based on Darrik's rmap work at:
> https://github.com/djwong/linux/tree/rmap-reflink-devel
> 
> Since this is based on a v4.5-rc kernel, it lacks pmem support for
> clearing badblocks on zeroing/writing, so those parts can't easily
> be tested yet. The clearing work is in 4.7-rs kernels, and once we
> rebase to that, that should also be available.

Just fyi, These patches should also cleanly apply to Darrick's for-next
rebase:
	https://github.com/djwong/linux/tree/djwong-devel

With this, I can now test badblock clearing also:

$ cat /sys/block/pmem7/badblocks 
122 1
124 1
126 1
128 1

$ sudo dd if=/dev/zero of=/dev/pmem7 bs=512 count=8 seek=120
oflag=direct
8+0 records in
8+0 records out
4096 bytes (4.1 kB) copied, 0.0206735 s, 198 kB/s

[  +9.510106] nd_pmem namespace7.0: pmem_clear_poison: 78 clear 1 sector
[  +0.001827] XFS (pmem7): xfs badblock cleared sector 120 (count 1)

[  +0.002772] nd_pmem namespace7.0: pmem_clear_poison: 7a clear 1 sector
[  +0.002527] XFS (pmem7): xfs badblock cleared sector 122 (count 1)

[  +0.003004] nd_pmem namespace7.0: pmem_clear_poison: 7c clear 1 sector
[  +0.002215] XFS (pmem7): xfs badblock cleared sector 124 (count 1)

[  +0.003063] nd_pmem namespace7.0: pmem_clear_poison: 7e clear 1 sector
[  +0.002307] XFS (pmem7): xfs badblock cleared sector 126 (count 1)


> 
> 
> Vishal Verma (2):
>   block, badblocks: add a notifier for badblocks
>   xfs: initial/partial support for badblocks
> 
>  block/badblocks.c         |  79 +++++++++++++++++++++++++++++++++--
>  fs/xfs/xfs_linux.h        |   1 +
>  fs/xfs/xfs_mount.c        | 104 ++++++++++++++++++++++++++++++++++++++++++++++
>  fs/xfs/xfs_mount.h        |   1 +
>  include/linux/badblocks.h |  19 +++++++++
>  5 files changed, 201 insertions(+), 3 deletions(-)
> 
> -- 
> 2.5.5
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  parent reply	other threads:[~2016-06-20 18:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-17  1:03 [RFC PATCH 0/2] Initial support for badblock checking in xfs Vishal Verma
2016-06-17  1:03 ` [RFC PATCH 1/2] block, badblocks: add a notifier for badblocks Vishal Verma
2016-06-17  1:03 ` [RFC PATCH 2/2] xfs: initial/partial support " Vishal Verma
2016-06-17  2:26   ` Darrick J. Wong
2016-06-17 19:26     ` Vishal Verma
2016-06-17 19:53       ` Darrick J. Wong
2016-06-17 20:32         ` Vishal Verma
2016-06-17 22:27           ` Dan Williams
2016-06-17  2:09 ` [RFC PATCH 0/2] Initial support for badblock checking in xfs Darrick J. Wong
2016-06-20 18:48 ` Vishal Verma [this message]
2016-06-24  1:40   ` Darrick J. Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160620184812.GA21878@omniknight.lm.intel.com \
    --to=vishal.l.verma@intel.com \
    --cc=darrick.wong@oracle.com \
    --cc=jack@suse.cz \
    --cc=linux-nvdimm@lists.01.org \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox