pacman-optimize: Is this bad?

iBertus · 2005-07-25 16:11:26

==> md5sum'ing the old database...
==> copying /var/lib/pacman...
==> md5sum'ing the new database...
==> checking integrity...
pacman-optimize: integrity check FAILED, reverting to old databse

What could cause this error? I ran this after noticing that pacman would freeze (and segfault) when trying to uninstall the big-ass kde group of packages. How can I fix this sort of problem?

phrakture · 2005-07-25 16:29:58

the integrity check means when it duplicated the library directory, they did not match... this could happen for a few reasons... are you running low on diskspace? did you change some filesystem parameters (someone else did this and got the same error) - if you'd like to opimize by hand:

cp -r /var/lib/pacman /var/lib/pacman-backup
rm -r /var/lib/pacman
mv /var/lib/pacman-backup /var/lib/pacman

this is what the script does, basically.... but seeing as it failed, I would be very careful when doing this...

iBertus · 2005-07-25 16:49:34

hmm... well, i'm not running low on space but i am running reiser4 on my /var partition. might try reverting back to something else and see if that fixes the issue.

T-Dawg · 2005-07-25 16:56:10

Have you tried the patch? It can be found in the bug tracker. I believe it replaces c with -c -same-order (something like that). If that doesn't solve your problem, consider filesystem issues as phrakture mentioned above.

dtw · 2005-07-25 17:26:07

I had the same problem and i am running reiser4 on my /var too...

iBertus · 2005-07-26 15:08:43

I've not switched /var from reiser4 to reiserfs 3.6. It seems that almost all of my reiser4 partitions that were made last week now fail fsck within the first 2 seconds. Strange when you consider that nothing bad has happened to this machine in that time period except normal usage.

iphitus · 2005-07-26 23:13:24

they fail fsck because there has been a change internally in reiser4's setup and the userspace tools have not been updated to reflect that.

iphitus

galiyosha · 2005-08-23 00:42:56

I have the same problem with pacman-optimize, although I use only ext3. I found out that although the MD5 sums of TAR files differ, running

diff -urN pacman pacman.bak

indicates the directories are essentially the same.

Isn't some sort of pacman redesign in progress that would lead into abandoning of this concept altogether and using something more fast and efficient for the database storage? (I'm just asking, no interest in flame of any kind...)

iBertus · 2005-08-23 01:04:53

galiyosha wrote:

I have the same problem with pacman-optimize, although I use only ext3. I found out that although the MD5 sums of TAR files differ, running
diff -urN pacman pacman.bak
indicates the directories are essentially the same.
Isn't some sort of pacman redesign in progress that would lead into abandoning of this concept altogether and using something more fast and efficient for the database storage? (I'm just asking, no interest in flame of any kind...)

I don't think that any sort of change will occur in the near future. There have been talks about using some sort of database engine for pacman but most people agree that the current system is the best for the Arch way of doing things.

phrakture · 2005-08-23 01:58:03

galiyosha wrote:

Isn't some sort of pacman redesign in progress that would lead into abandoning of this concept altogether and using something more fast and efficient for the database storage? (I'm just asking, no interest in flame of any kind...)

Yes. There are things being worked on, but alot of people don't experience any slowdown.... for me, I never notice any problems...

But the next release of pacman won't change the current system, but it will improve performance

galiyosha · 2005-08-27 13:17:16

phrakture wrote:

Yes. There are things being worked on, but alot of people don't experience any slowdown.... for me, I never notice any problems...

IMHO the reason most people don't experience any slowdown is that they run Arch Linux on a desktop with lots and lots of memory so their pacman db never comes out of cache. And even if it does, their 7200 rpm disks with blazing fast access times can handle this.

I know this has been reported over and over, but this is what it looks like on a notebook with an average 5400 rpm drive with an ext3 partition:

[gali@neutrino ~]$ time pacman -Ss rosegarden
extra/rosegarden 4.1.0-1
    audio and MIDI sequencer, score editor, and general-purpose music
    composition and editing application.

real    0m27.105s
user    0m0.394s
sys     0m0.660s

It used to be even worse -- around 45 seconds --, but I found another pacman directory under /var/lib/pacman/, so I had the entire repository tree nearly duplicated. I really don't know what caused this and whether if it was intentional, but guessing it wasn't, I just removed it. :-) du -hs /var/lib/pacman now comes out with only :-) 42 MB instead of the original 65 MB.

Moroever, when installing a package, after the last line of installing packagexyz... done, it takes another 15 or 20 seconds for pacman to finish.

And there are people out there still using 4200 rpm drives in their older notebooks...

Please, don't get me wrong. I'm totally happy with Arch, this is just a minor annoyance. But I think it deserves attention.

I was a longtime Windows user with only very passive Linux usage (several different reasons -- like a some gaming in the past, my sound card not being supported, etc.), but in July I finally switched over. For an ocassional use, Debian and Ubuntu was okay for me. But in a day-to-day manner, I just somehow couldn't feel at home there. Maybe because I felt the system is totally out of my control. (How ironic since I switched over from Windows. :-))

Now I'm using Arch for a month or so and never felt happier in Linux.

phrakture wrote:

But the next release of pacman won't change the current system, but it will improve performance

Well I'm certainly more than happy to hear this. :-)

Maybe if pacman was using a plugin system for its database. And user could choose between filesystem-based storage, sqlite3 or anything that would be available as a plugin. I'm quite sure it couldn't take so long to search through a 40 MB sqlite DB, even on a slower hard drive like mine. It shouldn't be too hard to implement too, if pacman uses some healthy amount of abstraction when retrieving data from its database... But I haven't looked at the source code, so I don't know. And I guess it would break the omnipresent KISS principle...

Hey, it was just an idea. :-)

Arch Linux

#1 2005-07-25 16:11:26

pacman-optimize: Is this bad?

#2 2005-07-25 16:29:58

Re: pacman-optimize: Is this bad?

#3 2005-07-25 16:49:34

Re: pacman-optimize: Is this bad?

#4 2005-07-25 16:56:10

Re: pacman-optimize: Is this bad?

#5 2005-07-25 17:26:07

Re: pacman-optimize: Is this bad?

#6 2005-07-26 15:08:43

Re: pacman-optimize: Is this bad?

#7 2005-07-26 23:13:24

Re: pacman-optimize: Is this bad?

#8 2005-08-23 00:42:56

Re: pacman-optimize: Is this bad?

#9 2005-08-23 01:04:53

Re: pacman-optimize: Is this bad?

#10 2005-08-23 01:58:03

Re: pacman-optimize: Is this bad?

#11 2005-08-27 13:17:16

Re: pacman-optimize: Is this bad?

Board footer