On Thu, Jun 02, 2022 at 05:42:13PM +0800, Shiyang Ruan wrote:
> Hi,
>
> Is there any other work I should do with these two patchsets? I think they
> are good for now. So... since the 5.19-rc1 is coming, could the
> notify_failure() part be merged as your plan?
Hmm. I don't see any of the
On Thu, 2 Jun 2022 10:18:09 -0700 "Darrick J. Wong" wrote:
> On Thu, Jun 02, 2022 at 05:42:13PM +0800, Shiyang Ruan wrote:
> > Hi,
> >
> > Is there any other work I should do with these two patchsets? I think they
> > are good for now. So... since the 5.19-rc1 is coming, could the
> >
Hi,
Is there any other work I should do with these two patchsets? I think
they are good for now. So... since the 5.19-rc1 is coming, could the
notify_failure() part be merged as your plan?
--
Thanks,
Ruan.
在 2022/5/12 20:27, Shiyang Ruan 写道:
在 2022/5/11 23:46, Dan Williams 写道:
On
On Sun, 8 May 2022 22:36:06 +0800 Shiyang Ruan wrote:
> This is a combination of two patchsets:
> 1.fsdax-rmap:
> https://lore.kernel.org/linux-xfs/20220419045045.1664996-1-ruansy.f...@fujitsu.com/
> 2.fsdax-reflink:
>
memory_failure_dev_pagemap code is a bit complex before introduce RMAP
feature for fsdax. So it is needed to factor some helper functions to
simplify these code.
Signed-off-by: Shiyang Ruan
Reviewed-by: Darrick J. Wong
Reviewed-by: Christoph Hellwig
Reviewed-by: Dan Williams
Reviewed-by:
When memory-failure occurs, we call this function which is implemented
by each kind of devices. For the fsdax case, pmem device driver
implements it. Pmem device driver will find out the filesystem in which
the corrupted page located in.
With dax_holder notify support, we are able to notify the
The current dax_lock_page() locks dax entry by obtaining mapping and
index in page. To support 1-to-N RMAP in NVDIMM, we need a new function
to lock a specific dax entry corresponding to this file's mapping,index.
And output the page corresponding to the specific dax entry for caller
use.
Changes since v1[1]:
1. Rebased to mm-unstable, solved many conflicts
[1]
https://lore.kernel.org/linux-xfs/20220508143620.1775214-1-ruansy.f...@fujitsu.com/
This is an *updated* combination of two patchsets:
1.fsdax-rmap:
In the case where the iomap is a write operation and iomap is not equal
to srcmap after iomap_begin, we consider it is a CoW operation.
In this case, the destination (iomap->addr) points to a newly allocated
extent. It is needed to copy the data from srcmap to the extent. In
theory, it is
To easily track filesystem from a pmem device, we introduce a holder for
dax_device structure, and also its operation. This holder is used to
remember who is using this dax_device:
- When it is the backend of a filesystem, the holder will be the
instance of this filesystem.
- When this pmem
Punch hole on a reflinked file needs dax_iomap_cow_copy() too.
Otherwise, data in not aligned area will be not correct. So, add the
CoW operation for not aligned case in dax_memzero().
Signed-off-by: Shiyang Ruan
Reviewed-by: Ritesh Harjani
Reviewed-by: Darrick J. Wong
Reviewed-by: Christoph
Introduce a PAGE_MAPPING_DAX_COW flag to support association with CoW file
mappings. In this case, since the dax-rmap has already took the
responsibility to look up for shared files by given dax page,
the page->mapping is no longer to used for rmap but for marking that
this dax page is shared.
Introduce xfs_notify_failure.c to handle failure related works, such as
implement ->notify_failure(), register/unregister dax holder in xfs, and
so on.
If the rmap feature of XFS enabled, we can query it to find files and
metadata which are associated with the corrupt data. For now all we do
is
With dax we cannot deal with readpage() etc. So, we create a dax
comparison function which is similar with
vfs_dedupe_file_range_compare().
And introduce dax_remap_file_range_prep() for filesystem use.
Signed-off-by: Goldwyn Rodrigues
Signed-off-by: Shiyang Ruan
Reviewed-by: Darrick J. Wong
Introduce xfs_mmaplock_two_inodes_and_break_dax_layout() for dax files
who are going to be deduped. After that, call compare range function
only when files are both DAX or not.
Signed-off-by: Shiyang Ruan
Reviewed-by: Darrick J. Wong
Reviewed-by: Christoph Hellwig
---
fs/xfs/xfs_file.c|
Replace the existing entry to the newly allocated one in case of CoW.
Also, we mark the entry as PAGECACHE_TAG_TOWRITE so writeback marks this
entry as writeprotected. This helps us snapshots so new write
pagefaults after snapshots trigger a CoW.
Signed-off-by: Goldwyn Rodrigues
Signed-off-by:
This new function is a variant of mf_generic_kill_procs that accepts a
file, offset pair instead of a struct to support multiple files sharing
a DAX mapping. It is intended to be called by the file systems as part
of the memory_failure handler after the file system performed a reverse
mapping
In fsdax mode, WRITE and ZERO on a shared extent need CoW performed.
After that, new allocated extents needs to be remapped to the file.
So, add a CoW identification in ->iomap_begin(), and implement
->iomap_end() to do the remapping work.
Signed-off-by: Shiyang Ruan
Reviewed-by: Darrick J. Wong
Add address output in dax_iomap_pfn() in order to perform a memcpy() in
CoW case. Since this function both output address and pfn, rename it to
dax_iomap_direct_access().
Signed-off-by: Shiyang Ruan
Reviewed-by: Christoph Hellwig
Reviewed-by: Ritesh Harjani
Reviewed-by: Dan Williams
在 2022/6/3 2:56, Andrew Morton 写道:
On Sun, 8 May 2022 22:36:06 +0800 Shiyang Ruan wrote:
This is a combination of two patchsets:
1.fsdax-rmap:
https://lore.kernel.org/linux-xfs/20220419045045.1664996-1-ruansy.f...@fujitsu.com/
2.fsdax-reflink:
在 2022/6/3 9:07, Shiyang Ruan 写道:
在 2022/6/3 2:56, Andrew Morton 写道:
On Sun, 8 May 2022 22:36:06 +0800 Shiyang Ruan
wrote:
This is a combination of two patchsets:
1.fsdax-rmap:
https://lore.kernel.org/linux-xfs/20220419045045.1664996-1-ruansy.f...@fujitsu.com/
2.fsdax-reflink:
21 matches
Mail list logo
