On Mon, 2020-09-28 at 10:56 -0500, Seebs wrote: > On Mon, 28 Sep 2020 15:51:53 +0100 > "Richard Purdie" <[email protected]> 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*.
Ultimately I agree. Lets plan that we need to put an abort() here. We're not quite at the point we can do that and I think changing the behaviour is a reasonable first step so I do plan to add this patch however I will plan some further patches to turn it into an abort(). How quickly I can do that will depend upon what kind of issues it throws up. > > 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. It helps to know that! I wasn't sure if you'd hate the path filtering. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#142880): https://lists.openembedded.org/g/openembedded-core/message/142880 Mute This Topic: https://lists.openembedded.org/mt/77174127/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
