[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: cryptsetup problem



On Mon, Jun 02, 2014 at 05:12:39AM +1000, Andrew McGlashan wrote:
> 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.
> 
> 
> 
[cut]
> 
> 
> 
> 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.

Just out of interest, are the arrays idle? If you're trying to sync the
arrays at the same time that you're trying to blank them, then there
will be a lot of disk activity.

> 
> 
> 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.

OK. So nothing has crashed, but the task has hung. Waiting for I/O would
cause this (but so would other things).

I would suggest the first stage might be to reduce your bs= value.
Transfer will be slower, but you'll get reports back more often.

Another tack might be to use cat, rather than pv on /dev/zero (so, cat
/dev/zero | pv ... | dd ...)

> [ 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-REQUEST@lists.debian.org 
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] 538B7B27.4080702@affinityvision.com.au">https://lists.debian.org/[🔎] 538B7B27.4080702@affinityvision.com.au
> 

Attachment: signature.asc
Description: Digital signature


Reply to: