Re: [PATCH 0/1] Uprev to pseudo 1.2

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2011-11-02 at 20:52 -0500, Mark Hatle wrote:
> On 11/2/11 5:47 PM, Martin Jansa wrote:
> > On Wed, Nov 02, 2011 at 05:31:59PM -0500, Mark Hatle wrote:
> >> On 11/2/11 5:11 PM, Martin Jansa wrote:
> >>> On Wed, Nov 02, 2011 at 04:39:42PM -0500, Mark Hatle wrote:
> >>>>> with pseudo.log full of errors like this
> >>>>> pseudo: path mismatch [12 links]: ino 39721500 db
> >>>>> '/OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/vim-7.2.446-r10.3/image/usr/share/vim/vim72/tutor'
> >>>>> req
> >>>>> '/OE/shr-core/tmp/work/om_gta02-oe-linux-gnueabi/task-shr-feed-1.0-r96'.
> >>>>
> >>>> Are you building on a NFS filesystem?  NFS (and a few other filesystems) have a
> >>>> habit of remapping inodes out from under the filesystem.  pseudo uses the inodes
> >>>> as a validation that the file hasn't changed.  If these inodes are changing,
> >>>> pseudo will do it's best to keep things in sync, but there is a chance it won't
> >>>> always succeed.
> >>>
> >>> No I'm building on local ext3 filesystem, but I'm also using rm_work, so 
> >>> /OE/shr-core/tmp/work/armv4t-oe-linux-gnueabi/vim-7.2.446-r10.3/image/usr/share/vim/vim72/tutor
> >>> is probably long gone and inode 39721500 wasn't marked as unused in
> >>> pseudo world or do I read it wrong?
> >>
> >> If you use rm_work, then the pseudo DB located within the work directory will
> >> also be removed.  So I'm not sure why you would be having such a large DB.
> > 
> > But I was talking about pseudo db here:
> > tmp/sysroots/x86_64-linux/var/pseudo/
> 
> I just checked my system and the logs in the sysroot isn't very large.  I'm
> curious as to why things are as big on your system.

We did have a problem a while back where pseudo was active when it
shouldn't have been and I noticed huge db/logs on my system too. The
environment changes that were pushed shortly before 1.1 fixed that
problem as far as I know but if this is an old build directory, it could
have those left behind.

This actually accounted for the significant load time bitbake had on one
of my systems too - it was spending the time loading the pseudo db.

Cheers,

Richard