On 2013-01-06 15:36:38, Zeev Zilberman wrote: > Hello, Hi Zeev! > > I've seen earlier discussions about ecryptfs ablkcipher patch, but I see > it was not merged. > Are you planning to apply this patch in the future, or did you decide to > drop it? Its status is somewhere between those two extremes. Not applied, but also not dropped. It is useful, but I'm not sure that its benefits outweigh the risks of merging it. The problem with the patch is that it didn't provide a clear performance increase across the board. I don't have the performance testing results handy, but it gave a nice increase on some systems and hurt performance on others. That, coupled with how risky the patch is, makes me hesitant to merge it. I don't currently have the bandwidth to provide the amount of testing that would be needed (nor the time to spend on fixing regressions) and the patch author has not been active in eCryptfs development for quite some time. In other words, no one has stepped up to usher the patch through. Very few eCryptfs users test the mainline -rc kernels and I don't want the users of whatever distro first ships this patch to find all of the regressions caused by it. > > I tried to apply the patch locally and saw the following issues: > > 1. I've encountered a problem with ecryptfs_encrypt_extent_done that is > calling functions > that can sleep (kmap/kunmap). It fails with ablkcipher crypto drivers that > invoke the > callback from interrupt handler bh (tasklet). > Moving the write part to a work queue (using queue_work) seems to solve it. Please send me patches, and cc this list, for these fixes. I will push everything to a branch in the eCryptfs git tree on kernel.org so that we don't lose any useful code. > > > 2. I saw that ecryptfs was reverted from writeback to writethrough cache > mode. That's correct > This seems to be problematic in regard to performance while using async > interfaces. > The original change to writepage (that uses ecryptfs_encrypt_page_async) > allowed > submitting async crypto operations and continuing without waiting for the > result. Nice catch, that would have to be changed. > write_end uses ecryptfs_encrypt_page (and needs its return value), so > we'll have to wait > for encryption (and write) to complete before continuing to the next > operation. > Are you planning to return ecryptfs cache to writeback mode? No, it caused quite a few bugs. I suspect that eCryptfs will stay with the writethrough cache. Have you done any performance testing yourself? I'm curious if you're interested in this patch because it made a significant difference in your use case. Tyler
Attachment:
signature.asc
Description: Digital signature
