Comment 6 for bug 431975

After taking a look at the call trace during a truncate that extends a file, eCryptfs could probably handle this in a more efficient way.

-> ecryptfs_setattr
 -> ecryptfs_truncate
  -> ecryptfs_write
...
   -> ecryptfs_get_locked_page
    -> ecryptfs_readpage
     -> ecryptfs_read_lower_page_segment
      -> kmap
      <- kmap
      -> ecryptfs_read_lower
      <- ecryptfs_read_lower
     <- ecryptfs_read_lower_page_segment
    <- ecryptfs_readpage
   <- ecryptfs_get_locked_page
   -> ecryptfs_encrypt_page
    -> alloc_pages_node").call
    <- alloc_pages_node").return
    -> kmap
    <- kmap
    -> ecryptfs_encrypt_extent
     -> ecryptfs_derive_iv
      -> ecryptfs_calculate_md5
      <- ecryptfs_calculate_md5
     <- ecryptfs_derive_iv
    <- ecryptfs_encrypt_extent
    -> ecryptfs_write_lower
    <- ecryptfs_write_lower
   <- ecryptfs_encrypt_page
...
  <- ecryptfs_write
 <- ecryptfs_truncate
<- ecryptfs_setattr

I don't think there's any need for the ecryptfs_readpage -> ecryptfs_read_lower_page_segment -> ecryptfs_read_lower sequence, as we know that we just need to encrypt a bunch of zeroes. Fixing that will improve performance, but the CPU is still likely to be pegged pretty high while doing all the encryption operations.

Improving the truncate path would really be a nice-to-have improvement, but I will probably not be able to devote much time to it. If someone wants to try to tackle it, I'll be more than happy to provide any help that I can.