On Thu, Dec 18, 2008 at 12:15 PM, Sivert Berg <sivertb@stud.ntnu.no> wrote:
On Tue, 16 Dec 2008 20:18:19 +0100 Xavier <shiningxc@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 : 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? 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 :)