Hello,
In the Message;
Subject : Re: [e-users] Bug in efl
Message-ID : <20240824123409.70fd00864b3b6faf936b6...@rasterman.com>
Date & Time: Sat, 24 Aug 2024 12:34:09 +0100
[CE] == Carsten Haitzler <ras...@rasterman.com> has written:
CE> On Sat, 24 Aug 2024 19:06:36 +0900 Masaru Nomiya <nom...@lake.dti.ne.jp>
said:
[...]
MN> > I have been doing this almost every day since August 3, but there has
MN> > been no change in the situation, and after reverting today, I finally
MN> > feel back to normal.
CE> disk contents have likely changed - more data or less data on
CE> disk. different numbers of files in different locations. more or
CE> less block fragmentation. more or less extents in files (more
CE> extents leads to more seeking and overhead).
There may have been a simdutf-derived DB structure problem in xapindb,
which is used when building recoll. I am thinking that this is the
case. I can smoothly take backups in the /home section, except for the
.recoll part.
In other words, the improvement was seen on Saturday, and the DB
structure problem was solved on Sunday, which brought about the
normalization of backups. I think.... The reason for this is that
simdutf is frequently being revised, and in fact, the upgrade was
performed on Saturday and Sunday, two days in a row, but the version
numbering is unnatural.
MN> > I was hesitant to report the bug because I thought there was a
MN> > possibility that you might be right, but today's result is too
MN> > different from the previous ones.... (_ _?
CE> look to see what is running and using i/o while you do a backup. iotop
might
CE> help.
Thanks, I'll try tomorrow.
CE> > Of cource, I also suspected memory and HDD, and used memtest86+ and
CE> > smartctl, but could not find anything wrong.
CE> >
CE> > What's wrong with me .....?
CE> memtest86 will look for bad memory - not relevant. as i said - that
CE> patch/commit is irrelevant. that code would not have even been
CE> compiled for you as you are not on ppc (i assume) so it's not
CE> relevant.
I never suspected simdutf, but it seems to be a recoll-related
problem, not a system problem, since the build of the loaded source
completes without problems. Indeed, simdutf frequently changes the way
it handles characters, which may be the cause of the problem.
Many Thanks,
---
┏━━┓彡 Masaru Nomiya mail-to: nomiya @ lake.dti.ne.jp
┃＼／彡
┗━━┛ "Japan was the future but it's stuck in the past"
-- Rupert Wingfield-Hayes (BBC) --
_______________________________________________
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
