On Mon, 2020-09-28 at 09:13 -0500, Seebs wrote: > On Mon, 28 Sep 2020 14:38:01 +0100 > "Richard Purdie" <[email protected]> wrote: > > > This can happen when files are deleted outside of pseudo context > > and > > the inode is reused by a new file which pseduo then "sees". > > I'm just going to say again: > > The **ENTIRE REASON** pseudo exists to replace fakeroot is that > fakeroot did this, and it consistently, repeatedly, reliably, > resulted in horrible database corruption.
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. > If files that pseudo knows about are being deleted outside the pseudo > context, that is violating a crucial precondition, and **you cannot > then trust the database to make sense**. Yes, you can throw away some > of the specific files when you detect them -- pseudo already did this > for specific cases, like directory vs plain file mismatches -- but > you should always view it as a serious bug in the rest of the > environment. > > If it's **really** necessary to allow things to corrupt the > filesystem, we need a way to tell pseudo of **specific** files that > it should be forgetting about or disregarding. I agree, which is why I spent the weekend making patch 3/4 work. The big win of the next patch is that it reduces the entries in the database to only the ones we actually care about. This doesn't tell pseudo about specific files but of specific directories of files. The result as mentioned in the patch is two orders of magnitude fewer files in some sample pseudo database and the files left are the ones we care about. Its not perfect, there are still a few that shouldn't be there but it is an improvement. I can't see any other way to handle this for the reasons I mention in the patches, the performance hit for tracking all files would be too great (and just moved the race window in many cases). > But, in general, "a thing that isn't under pseudo is modifying the > part of the filesystem pseudo thinks it owns" means "your entire > database is presumptively corrupt and you should not be guessing at > which parts of it might have survived that". > > I know it seems like this could conceivably be correct, but our > experience with attempts to fix it up in other ways was that it > always ended up resulting in very weird and incomprehensible > corruption. This patch tweaks one very specific corner case in a very specific way since I've seen first hand that the current behaviour causes corruption, I believe the alternative is safer. I'm actually making pseudo do less magic fixups rather than more! 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. 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. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#142854): https://lists.openembedded.org/g/openembedded-core/message/142854 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]] -=-=-=-=-=-=-=-=-=-=-=-
