From: | Alban Hertroys <haramrae(at)gmail(dot)com> |
---|---|
To: | Evgeny Morozov <postgresql3(at)realityexists(dot)net> |
Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, PostgreSQL General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: "PANIC: could not open critical system index 2662" - twice |
Date: | 2023-04-14 08:42:26 |
Message-ID: | A312EDE5-838F-4D81-BFA3-C269BAA3F68F@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> On 14 Apr 2023, at 9:38, Evgeny Morozov <postgresql3(at)realityexists(dot)net> wrote:
(…)
> I don't know whether ZFS zero-fills blocks on disk errors. As I
> understood, ZFS should have been able to recover from disk errors (that
> were "unrecoverable" at the hardware level) using the data on the other
> two disks (which did not report any errors). Thus, PG should not have
> seen any corrupted data (if ZFS was working correctly).
> https://unix.stackexchange.com/questions/341614/understanding-the-error-reporting-of-zfs-on-linux
> seems to confirm this. Am I misunderstanding something?
Your problem coincides with a thread at freebsd-current with very similar data corruption after a recent OpenZFS import: blocks of all zeroes, but also missing files. So, perhaps these problems are related?
Apparently, there was a recent fix for a data corruption issue with the block_cloning feature enabled, but people are still seeing corruption even when they never enabled that feature.
I couldn’t really find the start of the thread in the archives, so this one kind of jumps into the middle of the thread at a relevant-looking point:
https://lists.freebsd.org/archives/freebsd-current/2023-April/003446.html
Regards,
Alban Hertroys
--
There is always an exception to always.
From | Date | Subject | |
---|---|---|---|
Next Message | 黄宁 | 2023-04-14 11:04:16 | cursor with hold must be save to disk? |
Previous Message | Evgeny Morozov | 2023-04-14 07:38:42 | Re: "PANIC: could not open critical system index 2662" - twice |