Yes, rootfs it is one of the best patterns for default mode. But the most impressive performance numbers can be observed on a set of well-squeezable files, if you compress files with only even (or only odd) object IDs (and pass management to unix-file plugin for other files). This phenomenon is not yet investigated. Edward. On 08/07/2017 11:11 AM, Jose R Rodriguez wrote:
Niltze, all- Here is a link for reiser4 -patched kernel 4.11.12 end of life (EOL) source that I used to generate UDEB reiser4 modules, etc. for latest Metztli Reiser4 debian 9.1 Stretch netboot: < https://sourceforge.net/p/metztli-reiser4/code/ > Please note that upstream 4.11.12-for-4.11.11 patch was applied to debian kernel 4.11.11-1 and wrapped in its complementing version packaging – all hacked for smooth installation of pertinent patches. I have local and Google cloud Metztli Reiser4 instances running with above kernel. For the cloud this time I decided to try creating an image with (default) transparent compression reiser4 root fs. What surprised me is how fast and efficient the reiser4 transparent compression image performs in the Google cloud instance. I was expecting a noticeable performance penalty but so far it's extremely fast. I am still testing: < https://metztli.it/readOnlyEphemeral/gce-reiser4_transparent-compression.png > After local creation in VirtualBox and subsequent preparation and optimization for the Google Compute Engine (GCE), the image is tarred and uploaded to a Google storage repository - from there the image is added (via local SDK or web console) to an image debian family in one's project. If anyone is interested in the reiser4 transparent compression tarred image ~500MB for their Google Compute Engine project, please let me know. Best Professional Regards.
-- To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
