On 2/24/2020 4:26 PM, Dan Williams wrote:
On Mon, Feb 24, 2020 at 1:53 PM Jeff Moyer <jmoyer@xxxxxxxxxx> wrote:
Dan Williams <dan.j.williams@xxxxxxxxx> writes:
Let's just focus on reporting errors when we know we have them.
That's the problem in my eyes. If software needs to contend with
latent error reporting then it should always contend otherwise
software has multiple error models to wrangle.
The only way for an application to know that the data has been written
successfully would be to issue a read after every write. That's not a
performance hit most applications are willing to take. And, of course,
the media can still go bad at a later time, so it only guarantees the
data is accessible immediately after having been written.
What I'm suggesting is that we should not complete a write successfully
if we know that the data will not be retrievable. I wouldn't call this
adding an extra error model to contend with. Applications should
already be checking for errors on write.
Does that make sense? Are we talking past each other?
The badblock list is late to update in both directions, late to add
entries that the scrub needs to find and late to delete entries that
were inadvertently cleared by cache-line writes that did not first
ingest the poison for a read-modify-write. So I see the above as being
wishful in using the error list as the hard source of truth and
unfortunate to up-level all sub-sector error entries into full
PAGE_SIZE data offline events.
Sorry, don't mean to distract the discussion, but I'm wondering if
anyone has noticed SIGBUS with si_code = MCEERR_AO in a single process
poison test over a dax-xfs file? There is only 1 poison in the
file which has been consumed, it's the recovery code path (hole punch/
munmap/mmap/pwrite/read) that encounters the _AO. I'm confident that
latent error isn't the scenario per ARS scrub. Also, the _AO appears
rarely. This is un-explainable given the kernel MCE pmem handling
implementation.
I'm hoping we can find a way to make the error handling more fine
grained over time, but for the current patch, managing the blast
radius as PAGE_SIZE granularity at least matches the zero path with
the write path.
Maybe the new filesystem op for clearing pmem poison should insist on
4K alignment? because in hwpoison_clear() the starting pfn is given
by PHYS_PFN which rounds down to the nearest page, so we might inadvertently
clear the poison bit and 'noce' bit from a page when we only cleared a
poison e.g. in the second half of the page.
BTW, set_mce_nospec() doesn't seem to work in 5.5 release,
[ 2321.209382] Could not invalidate pfn=0x1850600 from 1:1 map
I will see if I can find more information.
Setting that aside we can start with just treating zeroing the same as
the copy_from_iter() case and fail the I/O at the dax_direct_access()
step.
OK.
I'd rather have a separate op that filesystems can use to clear errors
at block allocation time that can be enforced to have the correct
alignment.
So would file systems always call that routine instead of zeroing, or
would they first check to see if there are badblocks?
The proposal is that filesystems distinguish zeroing from free-block
allocation/initialization such that the fsdax implementation directs
initialization to a driver callback. This "initialization op" would
take care to check for poison and clear it. All other dax paths would
not consult the badblocks list.
thanks!
-jane
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@xxxxxxxxxxxx
To unsubscribe send an email to linux-nvdimm-leave@xxxxxxxxxxxx
