ems rather
unusual. Maybe dax_kill_mapping_procs? Also please add a kerneldoc
comment describing the function given that it exported.
OK. Thanks for your guidance.
--
Thanks,
Ruan Shiyang.
an example of 'unsigned long = unsigned long long', though it'll
work, it would be better to unify all the types.
Yes, I'll fix it.
--
Thanks,
Ruan Shiyang.
goto cow;
+ }
fallthrough;
case IOMAP_HOLE:
On 2021/2/10 下午9:19, Christoph Hellwig wrote:
On Tue, Feb 09, 2021 at 05:46:13PM +0800, Ruan Shiyang wrote:
On 2021/2/9 下午5:34, Christoph Hellwig wrote:
On Tue, Feb 09, 2021 at 05:15:13PM +0800, Ruan Shiyang wrote:
The dax dedupe comparison need the iomap_ops pointer as argument, so my
On 2021/2/18 下午4:32, Christoph Hellwig wrote:
On Wed, Feb 17, 2021 at 10:56:11AM +0800, Ruan Shiyang wrote:
I'd like to confirm one thing... I have checked all of this patchset by
checkpatch.pl and it did not report the overly long line warning. So, I
should still obey the rule of 80
PNOTSUPP;
+
+ if (!sb) {
+#ifdef CONFIG_SYSFS
+ rc = bd_disk_holder_corrupted_range(bdev, disk_off, len, data);
+#endif /* CONFIG_SYSFS */
Normal kernel convention is that you'd provide a empty shell for the
CONFIG_SYSFS=n case, e.g.
#ifdef CONFIG_SYSFS
int bd_corrupted_ran
(rmap_high));
+ rmap_low.rm_startblock = rmap_high.rm_startblock = agbno;
+ rmap_low.rm_blockcount = rmap_high.rm_blockcount = bcnt;
+
+ error = xfs_rmap_query_range(cur, &rmap_low, &rmap_high,
xfs_corrupt_helper, data);
Long line here...
+ if (error == -EFSCORRUPTED)
+
21/2/8/347
--
Thanks,
Ruan Shiyang.
Honza
(Rebased on v5.10)
==
Shiyang Ruan (7):
fsdax: Output address in dax_iomap_pfn() and rename it
fsdax: Introduce dax_copy_edges() for CoW
fsdax: Copy data before write
fsdax: Re
!sync);
+ if (srcmap.type != IOMAP_HOLE) {
Same here.
Thanks for suggestion. I'll try it.
--
Thanks,
Ruan Shiyang.
pos_out, len, remap_flags, NULL);
}
EXPORT_SYMBOL(generic_remap_file_range_prep);
```
Am i right?
--
Thanks,
Ruan Shiyang.
+extern int vfs_dedupe_file_range_compare(struct inode *src, loff_t srcoff,
+struct inode *dest, l
On 2021/2/9 下午5:34, Christoph Hellwig wrote:
On Tue, Feb 09, 2021 at 05:15:13PM +0800, Ruan Shiyang wrote:
The dax dedupe comparison need the iomap_ops pointer as argument, so my
understanding is that we don't modify the argument list of
generic_remap_file_range_prep(), but move its
and now that you've gotten me rambling about hwpoison, I wonder what
happens if dram backing part of the xfs buffer cache goes bad...
Yes, so many possible situations to consider. For the current stage,
just shutdown the filesystem if memory failures on metadata, and kill
user
d by filesystem.
--
Thanks,
Ruan Shiyang.
ther cases also need to be added here if to be implemented.
--
Thanks,
Ruan Shiyang.
+ tk->size_shift = dev_pagemap_mapping_shift(p, vma, tk->addr);
+ } else
tk->size_shift = page_shift(compound_head(p));
/*
@@ -495,7 +501,7 @@ static vo
this
information.
I did a lot of tries and finally found this way. I think I should add a
judgement that whether CONFIG_SYSFS is turned on.
--
Thanks,
Ruan Shiyang.
Honza
+
+ list_for_each_entry(holder,
On 2021/1/13 下午6:04, zhong jiang wrote:
On 2021/1/12 10:55 上午, Ruan Shiyang wrote:
On 2021/1/6 下午11:41, Jan Kara wrote:
On Thu 31-12-20 00:55:55, Shiyang Ruan wrote:
The current memory_failure_dev_pagemap() can only handle single-mapped
dax page for fsdax mode. The dax page could be
On 2021/1/5 上午7:34, Darrick J. Wong wrote:
On Fri, Dec 18, 2020 at 10:11:54AM +0800, Ruan Shiyang wrote:
On 2020/12/16 上午4:51, Darrick J. Wong wrote:
On Tue, Dec 15, 2020 at 08:14:13PM +0800, Shiyang Ruan wrote:
With the support of ->rmap(), it is possible to obtain the superblock o
On 2021/1/14 上午11:26, zhong jiang wrote:
On 2021/1/14 9:44 上午, Ruan Shiyang wrote:
On 2021/1/13 下午6:04, zhong jiang wrote:
On 2021/1/12 10:55 上午, Ruan Shiyang wrote:
On 2021/1/6 下午11:41, Jan Kara wrote:
On Thu 31-12-20 00:55:55, Shiyang Ruan wrote:
The current
;t be used to resolve the owner of physical page that
went bad
Yes, you are right. I made a mistake in the calling sequence here.
Thanks for pointing out.
--
Thanks,
Ruan Shiyang.
Cheers,
Dave.
hanks,
Ruan Shiyang.
thanks,
-jane
+ size_t len, void *data)
+{
+ return 0;
+}
static inline int bd_link_disk_holder(struct block_device *bdev,
struct gendisk *disk)
rblock by `get_super()`.
Usually, if we create filesystem directly on a pmem device, or make some
partitions at first, we can use `get_super()` to get the superblock. In
other case, such as creating a LVM on pmem device, `get_super()` does
not work.
So, I think refactoring it into a common he
ur = xfs_rmapbt_init_cursor(mp, tp, agf_bp, agno);
+
+ /* Construct a range for rmap query */
+ memset(&rmap_low, 0, sizeof(rmap_low));
+ memset(&rmap_high, 0xFF, sizeof(rmap_high));
+ rmap_low.rm_startblock = rmap_high.rm_startblock = agbno;
+ rmap_low.rm
ows
that the program is killed by SIGBUS. I cannot get any detail from it.
So, could you please show me the right way(test tools) to test it?
--
Thanks,
Ruan Shiyang.
thanks,
-jane
On 2020/12/18 上午11:49, Darrick J. Wong wrote:
On Fri, Dec 18, 2020 at 10:44:26AM +0800, Ruan Shiyang wrote:
On 2020/12/17 上午4:55, Jane Chu wrote:
Hi, Shiyang,
On 12/15/2020 4:14 AM, Shiyang Ruan wrote:
The call trace is like this:
memory_failure()
pgmap->ops->memory_f
page cache mapping case
mapping->a_ops->corrupt_range() =>
xfs_address_space_operations.xfs_xxx
memory_failure_generic_kill_procs()
It's rough and not completed yet. Hope for your comment.
--
Thanks,
Ruan Shiyang.
Cheers,
Dave.
ping
On 2021/1/26 上午10:13, Shiyang Ruan wrote:
The return value of range_parse() indicates the size when it is
positive. The error code should be negative.
Signed-off-by: Shiyang Ruan
---
drivers/dax/bus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dax/bus.
Hi guys,
any ideas?
--
Thanks,
Ruan Shiyang.
On 2020/11/26 下午12:03, Shiyang Ruan wrote:
The 'err' was assigned to -ENOMEM in just few lines above, no need to be
assigned again.
Signed-off-by: Shiyang Ruan
---
fs/fuse/dir.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/
ison? 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,
Ruan Shiyang.
Thanks!
-jane
othe
On 2020/4/28 下午2:43, Dave Chinner wrote:
On Tue, Apr 28, 2020 at 06:09:47AM +, Ruan, Shiyang wrote:
在 2020/4/27 20:28:36, "Matthew Wilcox" 写道:
On Mon, Apr 27, 2020 at 04:47:42PM +0800, Shiyang Ruan wrote:
This patchset is a try to resolve the shared 'page cac
On 2020/4/28 下午2:43, Dave Chinner wrote:
On Tue, Apr 28, 2020 at 06:09:47AM +, Ruan, Shiyang wrote:
在 2020/4/27 20:28:36, "Matthew Wilcox" 写道:
On Mon, Apr 27, 2020 at 04:47:42PM +0800, Shiyang Ruan wrote:
This patchset is a try to resolve the shared 'page cac
On 2020/6/4 下午10:51, Darrick J. Wong wrote:
On Thu, Jun 04, 2020 at 03:37:42PM +0800, Ruan Shiyang wrote:
On 2020/4/28 下午2:43, Dave Chinner wrote:
On Tue, Apr 28, 2020 at 06:09:47AM +, Ruan, Shiyang wrote:
在 2020/4/27 20:28:36, "Matthew Wilcox" 写道:
On Mon, Apr 27, 202
On 2020/6/5 上午9:30, Dave Chinner wrote:
On Thu, Jun 04, 2020 at 07:51:07AM -0700, Darrick J. Wong wrote:
On Thu, Jun 04, 2020 at 03:37:42PM +0800, Ruan Shiyang wrote:
On 2020/4/28 下午2:43, Dave Chinner wrote:
On Tue, Apr 28, 2020 at 06:09:47AM +, Ruan, Shiyang wrote:
在 2020/4/27 20
'll be
shooting down files on the data device, which will cause all sorts of
problems.
I didn't notice that. Let me think about it.
Question: Should all this poison recovery stuff go into a new file?
xfs_poison.c? There's already a lot of code in xfs_super.c.
Yes, it&#x
->storage_lost is required for all filesystems?
I think it is required for filesystems that support fsdax, since the
owner tracking is moved here. But anyway, there should have a non-NULL
judgment.
--
Thanks,
Ruan Shiyang.
--D
+
+out:
+ bdput(bdev);
+ return 0;
+}
33 matches
Mail list logo
