On Thu, Dec 18, 2008 at 12:15 PM, Sivert Berg <[email protected]> wrote: > On Tue, 16 Dec 2008 20:18:19 +0100 > Xavier <[email protected]> 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 :) _______________________________________________ pacman-dev mailing list [email protected] http://archlinux.org/mailman/listinfo/pacman-dev
