On Fri, 2023-09-15 at 15:29 +0100, Richard Purdie via
lists.openembedded.org wrote:
> On Fri, 2023-09-15 at 13:59 +0000, Peter Kjellerstedt wrote:
> >
> > While the problem the patch tried to fix is real, it seems a lot less
> > problematic than the result of applying the patch. So from a release
> > perspective, I would keep the current code and possibly add it as a
> > known bug to the release notes. Then, after the release is out, start
> > the work of solving the fallout from applying the patch, with the
> > intention to have it solved for the first point release of Nanbield.
> >
> > While not ideal, it sounds a lot less stressful than applying the
> > patch at this stage.
>
> My concern is the cache coherency issues this exposes.
>
> The 'easy' fix for release is explicit os.sync() calls in most command
> paths (everything except ping).
>
> I'm not sure I should really allow such a patch through review though
> as it would raise a lot of serious questions and the underlying issues
> need to be addressed.
Just to follow up with where I got to with this.
The problem is that inotify isn't delivering change notifications in a
timely fashion.
With the patch applied and BB_SERVER_TIMEOUT = "60", you can show an
issue with something like:
rm bitbake-cookerdaemon.log
bitbake-layers add-layer ../meta-virtualization/
bitbake-layers add-layer ../meta-openembedded/meta-oe/
bitbake -m
where the second add-layer fails with the same error as the first with
a message missing meta-virt dependencies. It doesn't notice
bblayers.conf has changed and hence doesn't re-parse the base
configuration. I've locally proven this is due to the inotify events
not arriving until after the parsing commands.
os.sync() isn't enough to flush the inotify backlog. os.system("sync")
does but that may be the fork overhead. sys.stdout.flush() does too,
probably as side effects in the kernel IO workings.
This basically brings me to the conclusion that it is hard to know when
the inotify events are in sync with the incoming command stream and the
current approach is flawed.
I'm starting to think that we should drop inotify and go back to stat
calls and maybe require that UIs send "re-scan cache" events so we can
avoid the scanning when we don't need to. The client code does have a
pretty good idea of when it changes metadata, it just doesn't share
that at the moment. We can rescan at reconnection so it would just
affect tinfoil usecases.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1764):
https://lists.openembedded.org/g/openembedded-architecture/message/1764
Mute This Topic: https://lists.openembedded.org/mt/101375777/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
