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@xxxxxxxxxx [ 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt