[pacman-dev] [PATCH 1/2] Added a new database backend

Xavier shiningxc at gmail.com
Thu Dec 18 07:10:07 EST 2008

On Thu, Dec 18, 2008 at 12:15 PM, Sivert Berg <sivertb at stud.ntnu.no> wrote:
> On Tue, 16 Dec 2008 20:18:19 +0100
> Xavier <shiningxc at gmail.com> wrote:
>> What about the disk space usage, compared to a simple tar file?
>> Did you ever consider the idea of reading directly tar.gz or
>> reading/writing directly tar, knowing we already have the libarchive
>> dependency.
> Well, if I understand tar files correctly, tar files require files to be
> stored in one continous chunk. If you want to update a file, and it
> gets bigger than it already is, you would have to move the whole file
> to the end of the archive. So while tar archives would work great for
> the sync db's that doesn't get modified, it would be hard to do for the
> local db, unless you rewrote the complete database every time you
> modified it. Now keeping two separate database formats for the sync
> and the local database seems a bit weird to me. As for the size:
> extra.db.tar:      5.3 mb
> extra.db (packed): 5.0 mb
> This is probably because the packed format uses 256 byte blocks, while
> tar uses 512 byte blocks, leading to less waste on small files in the
> packed format.

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 :
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
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 :)

More information about the pacman-dev mailing list