Messages in this thread | | | Subject | Re: [RFC PATCH v2 0/6] fsdax: introduce fs query to support reflink | From | Jane Chu <> | Date | Tue, 15 Dec 2020 11:05:07 -0800 |
| |
On 12/15/2020 3:58 AM, Ruan Shiyang wrote: > Hi Jane > > On 2020/12/15 上午4:58, Jane Chu wrote: >> 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? > > Recovering data for filesystem (or pmem device) has not been done in > this patchset... I just triggered the handler for the files sharing the > corrupted page here.
Thanks! That confirms my understanding.
With the framework provided by the patchset, how do you envision it to ease/simplify poison recovery from the user's perspective?
And how does it help in dealing with page faults upon poisoned dax page?
thanks! -jane
| |