I should say that there's also the possibility of writing a block device plugin which is highly tuned in some way to the Koji use case. We've already done discarding flushes and showed that you get all the benefit of a RAM disk just by doing that (even when backed by a disk). Is there anything else specific to Koji builds: - Prepopulating the filesystem in the block device? - Making a block device which is highly tuned to the filesystem it will contain (eg. keeping metadata in faster storage)? - Sharing / deduplicating? I collected traces of the access pattern of existing Koji builds, but they are huge and I'm not sure how best to analyze them. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ _______________________________________________ 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
