Re: [dm-crypt] Encrypting with larger packet size (+some experimental patch)

[Milan Broz <gmazyland@gmail.com>]

On 5.3.2013 12:53, Michael Stapelberg wrote:

> dd if=/dev/zero of=/dev/mapper/sda2_crypt bs=1M count=1024 oflag=direct
> 1073741824 bytes (1.1 GB) copied, 50.5507 s, 21.2 MB/s
>
> This is just to let you know where I am coming from :).
...

> dd if=/dev/zero of=/dev/mapper/sda2_crypt bs=1M count=1024 oflag=direct
> 1073741824 bytes (1.1 GB) copied, 26.4864 s, 40.5 MB/s

So 2 * performance increase? I would expect even more...
(Maybe compare it with new cryptsetup benchmark - in fact it uses much
larger block and it should measure almost real throughput or crypto engine.)

> I would appreciate it very much if you could implement the FIXME and
> commit that patch to dmcrypt.

As I said, it is on my TODO list, kernel support is only one part of the problem.
ANyway, I added http://code.google.com/p/cryptsetup/issues/detail?id=150 to track it.

> BTW, when using a block_size of more than 4096 (e.g. 8192),
> I get a kernel oops:
>
> [   36.601704] device-mapper: ioctl: 4.23.1-ioctl (2012-12-18) initialised: dm-devel@redhat.com
> [   36.658525] bio: create slab <bio-1> at 1
> [   36.672332] Unable to handle kernel NULL pointer dereference at virtual address 00000000

> [   37.026882] [<c00f44ec>] (create_empty_buffers+0x24/0x11c) from [<c00f4ad8>] (create_page_buffers+0x34/0x4c)
> [   37.036764] [<c00f4ad8>] (create_page_buffers+0x34/0x4c) from [<c00f4b14>] (block_read_full_page+0x24/0x358)
> [   37.046646] [<c00f4b14>] (block_read_full_page+0x24/0x358) from [<c009b434>] (__do_page_cache_readahead+0x194/0x1ec)
> [   37.057230] [<c009b434>] (__do_page_cache_readahead+0x194/0x1ec) from [<c009b6c4>] (force_page_cache_readahead+0x6c/0xa4)
> [   37.068240] [<c009b6c4>] (force_page_cache_readahead+0x6c/0xa4) from [<c0093d08>] (generic_file_aio_read+0x290/0x6dc)
> [   37.078906] [<c0093d08>] (generic_file_aio_read+0x290/0x6dc) from [<c00cd8b0>] (do_sync_read+0x90/0xcc)
> [   37.088348] [<c00cd8b0>] (do_sync_read+0x90/0xcc) from [<c00cdfb4>] (vfs_read+0xa4/0x17c)
> [   37.096569] [<c00cdfb4>] (vfs_read+0xa4/0x17c) from [<c00ce0c4>] (sys_read+0x38/0x64)
> [   37.104447] [<c00ce0c4>] (sys_read+0x38/0x64) from [<c000e380>] (ret_fast_syscall+0x0/0x2c)
> [   37.112924] Code: e1a05000 e1a03000 ea000000 e1a03001 (e5932000)
> [   37.119055] ---[ end trace c844ca55a4ae58f6 ]---

This looks like crash in different layer, IMHO this should happen even with other devices (try dm-linear).
If it is reproducible, perhaps report it to LKML.

Thanks,
Milan