Am 28.01.2017 um 13:37 schrieb Janos Toth F.:
> I usually compile my kernels with CONFIG_X86_RESERVE_LOW=640 and
> CONFIG_X86_CHECK_BIOS_CORRUPTION=N because 640 kilobyte seems like a
> very cheap price to pay in order to avoid worrying about this (and
> skip the associated checking + monitoring).
>
> Out of curiosity (after reading this email) I set these to 4 and Y (so
> 1 page = 4k reserve and checking turned ON and activated by default)
> on a useless laptop. Right after reboot, the kernel log was full of
> the same kind of Btrfs errors reported in the first email of this
> topic ("bad key order", etc). I could run a scrub with zero errors and
> successfully reboot with a read-write mounted root filesystem with the
> old kernel build (but the kernel log was still full of errors, as your
> might imagine). I tried to run "btrfs check --repair" but it seems to
> be useless in this situation, the filesystem needs to be recreated
> (not too hard in my case when it's still fully readable). Although,
> the kernel log was free of the "Corrupted low memory at" kind of
> messages (even though I let it run for hours).
Thanks for this report about the (even destructive...) test!
It's astonishing how fast this broke...
As mentioned in my last mail a few minutes ago, I am now following your example
and the machine is running with
CONFIG_X86_RESERVE_LOW=640
(but still with checking for the first 64k active). I consider using that for
all machines I'm administrating,
but it's interesting to see that major distributions targetting desktop use
stay with 64.
--
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
