On Fri, 8 May 2020 at 16:22, Stephen John Smoogen <smooge@xxxxxxxxx> wrote: > > On Fri, 8 May 2020 at 09:59, clime <clime@xxxxxxxxxxxxxxxxx> wrote: > > > > On Thu, 7 May 2020 at 20:58, Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > > > > > On Wed, May 06, 2020 at 08:39:19PM +0200, clime wrote: > > > ...snip... please folks... please trim your posts? :) > > > > > > > These are some great stats! > > > > > > > > But I would like to note that exploded repos (or source-git repos) > > > > have at least two other advantages. > > > > > > > > 1) they consume less space than tarballs for each version because > > > > objects in git repo are deduplicated > > > > > > But they consume tons more inodes which makes them painfull to > > > backup/restore/mirror. > > > > But maybe still less painful than to do this with upstream tarballs? > > No because the things that backups and rsync do works in a slow way. > We can do the backup the look-aside cache with tar-balls in a couple > of hours. We can also rsync that in the same amount of time. It takes > that long or longer to do that with a couple of git trees which are > much smaller in size but larger in file numbers. Every file in a git > tree is stat'd and while there is some deduplication, there is a lot > of files. Well from scratch, it will be much harder to rsync git repos but imho that changes once the initial rsync is done because then just new objects are transferred. + we could possibly use repospanner to mirror lookaside cache too? The deduplication in git is quite significant when compared to several tarballs from separate upstream releases. Anyway, I don't have the operative experience that you guys have so it's quite pointless for me to argue here. > > Could this be solved by moving to some other sort of file system > model... possibly but we > a) Have no time to pursue that investigation in a large enough size to > prove/disprove it > b) Have no money to purchase the equipment that these file systems work on. > > > > -- > Stephen J Smoogen. > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
