Thread (62 messages) 62 messages, 8 authors, 2021-11-06

Re: [dm-devel] [PATCH 0/6] dax poison recovery with RWF_RECOVERY_DATA flag

From: Christoph Hellwig <hch@infradead.org>
Date: 2021-10-22 05:38:12
Also in: dm-devel, linux-fsdevel, lkml, nvdimm

On Thu, Oct 21, 2021 at 06:58:17PM -0700, Darrick J. Wong wrote:
On Fri, Oct 22, 2021 at 01:37:28AM +0000, Jane Chu wrote:
quoted
On 10/21/2021 4:31 AM, Christoph Hellwig wrote:
quoted
Looking over the series I have serious doubts that overloading the
slow path clear poison operation over the fast path read/write
path is such a great idea.
Why would data recovery after a media error ever be considered a
fast/hot path?
Not sure what you're replying to (the text is from me, the mail you are
repling to is fom Jane), but my point is that the read/write
got path should not be overloaded with data recovery.
A normal read/write to a fsdax file would not pass the
flag, which skips the poison checking with whatever MCE consequences
that has, right?
Exactly!
pwritev2(..., RWF_RECOVER_DATA) should be infrequent enough that
carefully stepping around dax_direct_access only has to be faster than
restoring from backup, I hope?
Yes.  And thus be kept as separate as possible.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help