It would be nice if cptofs supported multiple source arguments

[copumpkin]

I think the LKL stuff takes some time to initialize, which makes repeated calls to cptofs rather slow.

[petrosagg]

I found that the inialisation is slow only because the kernel does some performance tests to select the fastest algorithm for raid6 and xor, both of which are dependencies of btrfs. If you compile LKL without btrfs support initialisation is almost instantaneous.

There are runtime performance tests for gen_syndrome, raid recover, and XOR functions. For XOR, an architecture can short-circuit the test and pre-select an algorithm by defining XOR_SELECT_TEMPLATE. x86 does this but lkl doesn't.

Would it make sense to set XOR_SELECT_TEMPLATE in lkl's arch and also short-circuit the raid6 tests by patching them?

[tavip]

@copumpkin Closing this now that #298 was merged.

@petrosagg I think the best way to solve the slow start issue is to implement loadable modules and compile btrfs and the dependecies as modules. That is tracked in #63. I am working on that, but I think it is still a few weeks until completion. Feel free to open a new issue if you need a faster resolution, and in that case we can do the temporary patch which we can revert when module support arrives.

[copumpkin]

Thanks! I'll keep an eye on the loadable modules, which sounds really cool. Definitely not in a rush, now that I have something that works fine.

[thehajime]

@petrosagg I think the best way to solve the slow start issue is to implement loadable modules and compile btrfs and the dependecies as modules. That is tracked in #63. I am working on that, but I think it is still a few weeks until completion. Feel free to open a new issue if you need a faster resolution, and in that case we can do the temporary patch which we can revert when module support arrives.

although loadable module sounds nice, the slow start issue is different one I think (you will face the same issue when loading an object file of btrfs).

I filed an issue for that (#301).