On Thu, 18 Dec 2008 13:10:07 +0100 Xavier <shiningxc@gmail.com> wrote:
Hm ok, I don't know much about the subject, but I would like to get idea of the "code complexity" / "performance gain" ratio compared to the other ideas or existing solutions. Another one I have in mind is the ext2 on loopback fs way : http://bbs.archlinux.org/viewtopic.php?id=20385 Isn't the result a bit similar, but instead of having to implement it ourself in pacman, we can just re-use stable and working kernel filesystems?
Well, I guess that's a possibility. However you can't resize loopback devices just like that. So either you have to make it so big you'll never need to resize it, or when you need to resize, make a new loopback device, make a filesystem on it, copy over the old database and then start using the new loopback device. Is that really so much easier than having the "fs" code in pacman? If you look at be_packed.h (which is where all the database code is) you see it's only about 750 lines and it shouldn't be that hard to make that into good, stable code.
Doing it on pacman level reduces the layers so could increase the performance, and also probably allows a better control on flexibility, but I still wonder if it is worth it. Again I don't know much, so correct me if I am wrong and enlighten me :)
In my opinion anything that is able to cut down the runtime of "pacman -Ss" from 50 to 2 seconds on a database that isn't cached yet is worth it. Might just be me being impatient though :) -- Sivert Berg <sivertb@stud.ntnu.no>