[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <89ab4ec4-e4f0-7c17-6982-4f55bb40f574@oracle.com>
Date: Mon, 14 Dec 2020 12:58:32 -0800
From: Jane Chu <jane.chu@...cle.com>
To: Shiyang Ruan <ruansy.fnst@...fujitsu.com>,
linux-kernel@...r.kernel.org, linux-xfs@...r.kernel.org,
linux-nvdimm@...ts.01.org, linux-mm@...ck.org
Cc: linux-fsdevel@...r.kernel.org, linux-raid@...r.kernel.org,
darrick.wong@...cle.com, dan.j.williams@...el.com,
david@...morbit.com, hch@....de, song@...nel.org, rgoldwyn@...e.de,
qi.fuli@...itsu.com, y-goto@...itsu.com
Subject: Re: [RFC PATCH v2 0/6] fsdax: introduce fs query to support reflink
Hi, Shiyang,
On 11/22/2020 4:41 PM, Shiyang Ruan wrote:
> This patchset is a try to resolve the problem of tracking shared page
> for fsdax.
>
> Change from v1:
> - Intorduce ->block_lost() for block device
> - Support mapped device
> - Add 'not available' warning for realtime device in XFS
> - Rebased to v5.10-rc1
>
> This patchset moves owner tracking from dax_assocaite_entry() to pmem
> device, by introducing an interface ->memory_failure() of struct
> pagemap. The interface is called by memory_failure() in mm, and
> implemented by pmem device. Then pmem device calls its ->block_lost()
> to find the filesystem which the damaged page located in, and call
> ->storage_lost() to track files or metadata assocaited with this page.
> Finally we are able to try to fix the damaged data in filesystem and do
Does that mean clearing poison? if so, would you mind to elaborate
specifically which change does that?
Thanks!
-jane
> other necessary processing, such as killing processes who are using the
> files affected.
Powered by blists - more mailing lists