Hi, I am trying to write /dev/zero across an entire RAID1 encrypted volume.
The RAID1 partition is new, I opened it fine with ".... luksOpen ..." and the next step is to write the /dev/zero across the whole partition. Right now I am working in a crafted [with extra tools] dropbear environment, but the same thing occurred in the normal environment. Some further details follow, any ideas would be appreciated. My next inclination now is to allow mdadm to complete the mirroring before opening the crypt volume and then writing /dev/zero to the whole volume. So, not opening the crypt volume until it is fully mirrored. ~/wrk # uname -a Linux n4800eco-a 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3 x86_64 GNU/Linux [this is wheezy 7.5] ~/wrk # time pv -tpreb /dev/zero | dd of=/dev/mapper/md1_crypt bs=128M 148GB 0:50:53 [ 12MB/s] [ <=> ] Some operations seem to hang at the point of the failure. md0 is all good: # /sbin/mdadm -D /dev/md0 /dev/md0: Version : 1.2 Creation Time : Sat Jun 1 02:40:35 2013 Raid Level : raid1 Array Size : 291520 (284.74 MiB 298.52 MB) Used Dev Size : 291520 (284.74 MiB 298.52 MB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Sun Jun 1 16:35:06 2014 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Name : affinity-n54l-a:0 (local to host affinity-n54l-a) UUID : 3e1a27ad:66ade44e:c0e4f5bb:68ae0cd8 Events : 135 Number Major Minor RaidDevice State 0 8 17 0 active sync /dev/sdb1 2 8 1 1 active sync /dev/sda1 md1 has problems.... ~ # /sbin/mdadm -D /dev/md1 [no response no matter how long I waited] ~ # /sbin/lvm lvm> vgscan Reading all physical volumes. This may take a while... [also no response no matter how long I waited] The disks were previously tested successfully with badblocks _before_ creating any mirrors in the dropbear environment. All I seem to be able to do is reboot the box and start again, but it fails every time with the same symptoms. Here is some more output: ~ # cat /proc/mdstat Personalities : [raid1] md2 : active (auto-read-only) raid1 sdd2[0] sde2[1] 3883658048 blocks super 1.2 [2/2] [UU] resync=PENDING md1 : active raid1 sdb2[0] sdc2[1] 3883658048 blocks super 1.2 [2/2] [UU] [>....................] resync = 0.0% (3002496/3883658048) finish=4557145.5min speed=14K/sec md0 : active (auto-read-only) raid1 sdb1[0] sdd1[2] sde1[3] sdc1[1] 11709312 blocks super 1.2 [4/4] [UUUU] unused devices: <none> The very small md0 crypt RAID1 volume is happy: ~ # /sbin/cryptsetup status md0_crypt /dev/mapper/md0_crypt is active. type: LUKS1 cipher: aes-xts-plain64 keysize: 512 bits device: /dev/md0 offset: 4096 sectors size: 23414528 sectors mode: read/write But not the md1 crypt RAID1 volume.... :( ~ # /sbin/cryptsetup status md1_crypt /dev/mapper/md1_crypt is active and is in use. [then nothing more again, so just 1 line of output] dmesg includes this: [ 434.875573] md: resync of RAID array md1 [ 434.875582] md: minimum _guaranteed_ speed: 1000 KB/sec/disk. [ 434.875588] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for resync. [ 434.875598] md: using 128k window, over a total of 3883658048k. Then a bunch of messages like this (until it seems to stop doing anything further) : [ 3839.679711] INFO: task kworker/3:3:392 blocked for more than 120 seconds. [ 3839.679715] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 3839.679718] kworker/3:3 D ffff88007d393780 0 392 2 0x00000000 [ 3839.679725] ffff880036a1d7c0 0000000000000046 ffff880000000000 ffff88007a453100 [ 3839.679733] 0000000000013780 ffff88005aed5fd8 ffff88005aed5fd8 ffff880036a1d7c0 [ 3839.679741] ffff8800368aff58 0000000181071069 0000000000000046 ffff88003690ac80 [ 3839.679749] Call Trace: [ 3839.679757] [<ffffffffa00bfb2e>] ? wait_barrier+0xd7/0x118 [raid1] [ 3839.679763] [<ffffffff8103f6e2>] ? try_to_wake_up+0x197/0x197 [ 3839.679770] [<ffffffffa00c298b>] ? make_request+0x111/0xa5b [raid1] [ 3839.679777] [<ffffffffa0135712>] ? crypto_aes_decrypt_x86+0x5/0x5 [aes_x86_64] [ 3839.679784] [<ffffffffa0135712>] ? crypto_aes_decrypt_x86+0x5/0x5 [aes_x86_64] [ 3839.679791] [<ffffffffa012523a>] ? encrypt+0x3f/0x44 [xts] [ 3839.679803] [<ffffffffa00d3d47>] ? md_make_request+0xee/0x1db [md_mod] [ 3839.679809] [<ffffffff81036628>] ? should_resched+0x5/0x23 [ 3839.679814] [<ffffffff8134e714>] ? _cond_resched+0x7/0x1c [ 3839.679821] [<ffffffff8119969e>] ? generic_make_request+0x90/0xcf [ 3839.679829] [<ffffffffa00e92c9>] ? kcryptd_crypt+0x1f7/0x331 [dm_crypt] [ 3839.679835] [<ffffffff8105b5cf>] ? process_one_work+0x161/0x269 [ 3839.679841] [<ffffffff8105ab7b>] ? cwq_activate_delayed_work+0x3c/0x48 [ 3839.679847] [<ffffffff8105c598>] ? worker_thread+0xc2/0x145 [ 3839.679853] [<ffffffff8105c4d6>] ? manage_workers.isra.25+0x15b/0x15b [ 3839.679860] [<ffffffff8105f6d9>] ? kthread+0x76/0x7e [ 3839.679866] [<ffffffff81356b74>] ? kernel_thread_helper+0x4/0x10 [ 3839.679873] [<ffffffff8105f663>] ? kthread_worker_fn+0x139/0x139 [ 3839.679879] [<ffffffff81356b70>] ? gs_change+0x13/0x13 -- Kind Regards AndrewM -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/538b7b27.4080...@affinityvision.com.au