On Mon, 28 Sep 2020 15:51:53 +0100 "Richard Purdie" <richard.pur...@linuxfoundation.org> wrote:
> I understand. I have strong evidence that the current handling of such > a case does the wrong thing though as copying the data from the > original inode leads to pretty bad corruption in its own right. Yes. But if you had to choose between (1) discard the possibly-bad data, and (2) abort(), 2 would be a MUCH better fix. Don't treat this as a thing to be worked around. Treat it as a giant red flag that *we no longer have a sound reason to think that the database is valid*. > In many ways I'd like to make these corner cases hard errors. In order > to do that we need to ensure we're not hitting them though and to do > that we need the next patch. Yeah. > Once we have the ability to ignore subtrees, we could just hard error > for the potential corruption cases and force those issues to be > addressed properly. I think that is the right path. -s
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#142860): https://lists.openembedded.org/g/openembedded-core/message/142860 Mute This Topic: https://lists.openembedded.org/mt/77174127/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
