On Mon, Dec 07, 2015 at 03:37:43PM +0100, David Sterba wrote:
> On Fri, Dec 04, 2015 at 09:58:04AM -0800, Liu Bo wrote:
> > This disables repair process on ro cases as it can cause system
> > to be unresponsive on the ASSERT() in repair_io_failure().
> >
> > This can happen when scrub is running and a hardware error pops up,
> > we should fallback to ro mounts gracefully instead of being unresponsive.
>
> So this will also report the error as uncorrectable. This might be a bit
> misleading, if a device error happens first and then some potentially
> corectable errors are detected. This could be accounted as 'unverified'
> error, that has closet maning.
Make sense, we can do
if (ret < 0 && ret == -EROFS)
spin_lock();
unverified++;
spin_unlock()
However, in scrub_fixup_nodatasum() all errors including ENOMEM of path
allocation and failure of trans are interpreted to 'uncorrectable', So I
wander it means this 'uncorrectable' is only valid in this scrub process?
Thanks,
-liubo
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
