cryptsetup problem
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
Reply to: