* Writing to a DM snapshot blocks for a long time
@ 2012-08-16 17:55 David Shaw
0 siblings, 0 replies; 3+ messages in thread
From: David Shaw @ 2012-08-16 17:55 UTC (permalink / raw)
To: dm-devel
Hello,
I'm seeing some odd behavior using DM snapshots, and I was hoping someone here could help shed some light on it. What I'm doing is creating a snapshot using DM directly (not through LVM), mounting the snapshot, and then writing to both sides (the mounted snapshot as well as the original filesystem). The data written to the snapshot goes away after I tear it down, of course.
I managed to get this down to a simple reproduction case. All this is starting with a LVM VG named "tests", which contains two LVs named "original" and "cow". The "original" LV is formatted ext4 and mounted on /original.
1) time dd if=/dev/zero bs=16384 count=1 of=/original/zeroes
2) dmsetup suspend tests-original
3) dmsetup table tests-original | dmsetup create tests-original-backup
4) echo 0 `blockdev --getsz /dev/mapper/tests-original` snapshot-origin /dev/mapper/tests-original-backup | dmsetup reload tests-original
5) echo 0 `blockdev --getsz /dev/mapper/tests-original-backup` snapshot /dev/mapper/tests-original-backup /dev/mapper/tests-cow N 1024 | dmsetup create tests-snap
6) dmsetup resume tests-original
7) mount /dev/mapper/tests-snap /snap
So far so good - original is mounted on /original, the snapshot is mounted on /snap. Now here comes the problem:
8) time dd if=/dev/zero bs=16384 count=1 of=/snap/zeroes
Writing to the snapshot blocks for a long time (60-180 seconds). Doing a strace of the dd shows it blocking in write(). Note that /snap/zeroes is overwriting (the snapshot version of) the /original/zeroes file written in step 1. If this isn't an overwrite (if, for example, the dd wrote to "/snap/a-different-filename"), there is no blocking. Similarly, there is no problem writing to anything under "/original".
Test cleanup steps that work without any problem:
9) umount /snap
10) dmsetup suspend tests-original
11) dmsetup table tests-original-backup | dmsetup reload tests-original
12) dmsetup remove tests-snap
13) dmsetup resume tests-original
14) dmsetup remove tests-original-backup
The kernel in question is kernel-PAE-2.6.35.14-97.fc14.i686 (i.e. Fedora 14). It's running on a Dell R410 with 16 gigs of RAM. The PV the VG resides on is a 4-disk RAID5 using the Dell PERC 6 RAID card (from the LVM perspective, it just sees a single block device from the card here).
I captured this trace (via 'echo t > /proc/sysrq-trigger') of a cp stuck in write() while writing to the snapshot:
2012-08-14 13:15:39 foobar kernel: [ 6707.239661] cp D e2059970 0 15809 15803 0x00000000
2012-08-14 13:15:39 foobar kernel: [ 6707.239664] e20599a0 00000086 afd59283 e2059970 c0ac4f00 c0ac4f00 c0ac4f00 c0ac4f00
2012-08-14 13:15:39 foobar kernel: [ 6707.239668] c0ac4f00 f210ce4c a6974267 00000619 c0ac4f00 00000000 00000619 f210cbc0
2012-08-14 13:15:39 foobar kernel: [ 6707.239671] 00000001 ce84935c f210cbc0 e20599f0 e20599b0 c07b8ddd e20599e8 00000000
2012-08-14 13:15:39 foobar kernel: [ 6707.239675] Call Trace:
2012-08-14 13:15:39 foobar kernel: [ 6707.239678] [<c07b8ddd>] io_schedule+0x3c/0x53
2012-08-14 13:15:39 foobar kernel: [ 6707.239680] [<c04ff5b3>] sync_buffer+0x27/0x2b
2012-08-14 13:15:39 foobar kernel: [ 6707.239682] [<c07b929c>] __wait_on_bit+0x39/0x60
2012-08-14 13:15:39 foobar kernel: [ 6707.239684] [<c04ff58c>] ? sync_buffer+0x0/0x2b
2012-08-14 13:15:39 foobar kernel: [ 6707.239687] [<c07b931f>] out_of_line_wait_on_bit+0x5c/0x64
2012-08-14 13:15:39 foobar kernel: [ 6707.239689] [<c04ff58c>] ? sync_buffer+0x0/0x2b
2012-08-14 13:15:39 foobar kernel: [ 6707.239692] [<c045523a>] ? wake_bit_function+0x0/0x52
2012-08-14 13:15:39 foobar kernel: [ 6707.239694] [<c04ff552>] __wait_on_buffer+0x1e/0x21
2012-08-14 13:15:39 foobar kernel: [ 6707.239698] [<c055c4b0>] ext4_mb_init_cache+0x20b/0x452
2012-08-14 13:15:39 foobar kernel: [ 6707.239702] [<c055d0f9>] ext4_mb_init_group+0x9f/0x1a4
2012-08-14 13:15:39 foobar kernel: [ 6707.239705] [<c055e14d>] ext4_mb_good_group+0x4e/0xc6
2012-08-14 13:15:39 foobar kernel: [ 6707.239708] [<c055e2db>] ext4_mb_regular_allocator+0x116/0x240
2012-08-14 13:15:39 foobar kernel: [ 6707.239711] [<c055b5fc>] ? ext4_mb_initialize_context+0x1d4/0x1de
2012-08-14 13:15:39 foobar kernel: [ 6707.239714] [<c055ee60>] ext4_mb_new_blocks+0x18b/0x390
2012-08-14 13:15:39 foobar kernel: [ 6707.239717] [<c04d6a89>] ? __raw_local_irq_save+0x19/0x1e
2012-08-14 13:15:39 foobar kernel: [ 6707.239720] [<c0558724>] ext4_ext_map_blocks+0x12df/0x1547
2012-08-14 13:15:39 foobar kernel: [ 6707.239723] [<c04b15b5>] ? mempool_alloc_slab+0x13/0x15
2012-08-14 13:15:39 foobar kernel: [ 6707.239725] [<c04d6a89>] ? __raw_local_irq_save+0x19/0x1e
2012-08-14 13:15:39 foobar kernel: [ 6707.239728] [<c04d9595>] ? kmem_cache_alloc+0x7c/0xda
2012-08-14 13:15:39 foobar kernel: [ 6707.239730] [<c0502b01>] ? bio_free+0x4f/0x52
2012-08-14 13:15:39 foobar kernel: [ 6707.239733] [<c04d6a89>] ? __raw_local_irq_save+0x19/0x1e
2012-08-14 13:15:39 foobar kernel: [ 6707.239735] [<c04d9595>] ? kmem_cache_alloc+0x7c/0xda
2012-08-14 13:15:39 foobar kernel: [ 6707.239738] [<c04b15b5>] ? mempool_alloc_slab+0x13/0x15
2012-08-14 13:15:39 foobar kernel: [ 6707.239740] [<c04b15b5>] ? mempool_alloc_slab+0x13/0x15
2012-08-14 13:15:39 foobar kernel: [ 6707.239742] [<c04b170e>] ? mempool_alloc+0x5c/0xeb
2012-08-14 13:15:39 foobar kernel: [ 6707.239745] [<c0542592>] ext4_map_blocks+0x109/0x1c6
2012-08-14 13:15:39 foobar kernel: [ 6707.239747] [<c05426de>] _ext4_get_block+0x8f/0x105
2012-08-14 13:15:39 foobar kernel: [ 6707.239750] [<c05427b9>] ext4_get_block+0x1b/0x20
2012-08-14 13:15:39 foobar kernel: [ 6707.239752] [<c05008e0>] __block_prepare_write+0x11b/0x268
2012-08-14 13:15:39 foobar kernel: [ 6707.239755] [<c0500ad0>] block_write_begin_newtrunc+0x6d/0xa0
2012-08-14 13:15:39 foobar kernel: [ 6707.239757] [<c054279e>] ? ext4_get_block+0x0/0x20
2012-08-14 13:15:39 foobar kernel: [ 6707.239761] [<c04bf1bc>] ? __inc_zone_page_state+0x1d/0x1f
2012-08-14 13:15:39 foobar kernel: [ 6707.239763] [<c0500d8d>] block_write_begin+0x28/0x62
2012-08-14 13:15:39 foobar kernel: [ 6707.239765] [<c054279e>] ? ext4_get_block+0x0/0x20
2012-08-14 13:15:39 foobar kernel: [ 6707.239768] [<c0543631>] ext4_write_begin+0x117/0x1ec
2012-08-14 13:15:39 foobar kernel: [ 6707.239770] [<c054279e>] ? ext4_get_block+0x0/0x20
2012-08-14 13:15:39 foobar kernel: [ 6707.239774] [<c04af7ad>] generic_file_buffered_write+0xb6/0x1a3
2012-08-14 13:15:39 foobar kernel: [ 6707.239777] [<c04b0ce1>] __generic_file_aio_write+0x25b/0x283
2012-08-14 13:15:39 foobar kernel: [ 6707.239780] [<c042e0bd>] ? kunmap_atomic+0x50/0x76
2012-08-14 13:15:39 foobar kernel: [ 6707.239783] [<c0430b5a>] ? need_resched+0x19/0x23
2012-08-14 13:15:39 foobar kernel: [ 6707.239786] [<c04b0d63>] generic_file_aio_write+0x5a/0xa4
2012-08-14 13:15:39 foobar kernel: [ 6707.239789] [<c053cd23>] ext4_file_write+0x91/0xa2
2012-08-14 13:15:39 foobar kernel: [ 6707.239792] [<c04e320c>] do_sync_write+0x8f/0xca
2012-08-14 13:15:39 foobar kernel: [ 6707.239796] [<c0585a89>] ? security_file_permission+0x14/0x16
2012-08-14 13:15:39 foobar kernel: [ 6707.239798] [<c04e3610>] ? rw_verify_area+0x95/0xb1
2012-08-14 13:15:39 foobar kernel: [ 6707.239800] [<c04e317d>] ? do_sync_write+0x0/0xca
2012-08-14 13:15:39 foobar kernel: [ 6707.239803] [<c04e38ab>] vfs_write+0x87/0xdf
2012-08-14 13:15:39 foobar kernel: [ 6707.239806] [<c07bcece>] ? do_page_fault+0x219/0x275
2012-08-14 13:15:39 foobar kernel: [ 6707.239808] [<c04e3a81>] sys_write+0x40/0x62
2012-08-14 13:15:39 foobar kernel: [ 6707.239811] [<c040895f>] sysenter_do_call+0x12/0x28
Any advice would be very much appreciated.
David
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Writing to a DM snapshot blocks for a long time
[not found] ` <alpine.DEB.2.10.1305072201090.13746@trent.utfs.org>
@ 2013-05-08 17:07 ` David Shaw
0 siblings, 0 replies; 3+ messages in thread
From: David Shaw @ 2013-05-08 17:07 UTC (permalink / raw)
To: Christian Kujau; +Cc: dm-devel, ext3-users
On May 8, 2013, at 1:05 AM, Christian Kujau <lists@nerdbynature.de> wrote:
> On Mon, 6 May 2013 at 17:16, David Shaw wrote:
>> What I'm doing is creating a snapshot using DM directly (not through
>> LVM), mounting the snapshot, and then writing to both sides (the mounted
>> snapshot as well as the original filesystem).
> [...]
>> I managed to get this down to a simple reproduction case. All this
>> is starting with a LVM VG named "tests", which contains two LVs named
>
> I'm confused: are your using LVM or not?
In effect, yes, I am. The only difference is that I'm calling the dmsetup commands manually rather than creating the snapshot via lvcreate.
My apologies - I think in an effort to be complete, I used way too much verbiage and confused the issue. To restate this in a simpler way: I create a LVM snapshot of a large (~6TB) ext4 filesystem, then mount it. On occasion (so this is not 100% reproducible) overwriting a file on the snapshot blocks for a long time (~60 seconds) before completing. I can write to the origin volume without any problem, and I can write new files to the snapshot without any problem. It's only when overwriting a file on the snapshot (i.e. a file that exists on the origin, but I'm overwriting it on the snapshot) does the block happen. Once the initial blockage has passed, things generally proceed without any further blockage.
I got a backtrace via "echo t > /proc/sysrq-trigger" of /bin/cp stuck in this state, which is pasted below.
A week or two ago, there was a post here about "(LONG) Delay when writing to ext4 LVM after boot". Reading that post over again, it sounds somewhat similar, at least in symptoms. My case isn't a new boot, but the snapshot is certainly a newly-mounted filesystem. FWIW, flex_bg is set on my filesystem. The flex block group size is 16. A possibly useful tidbit is that both the snap and origin are mounted nodelalloc.
> $ uname -rv
> 3.8-trunk-amd64 #1 SMP Debian 3.8-1~experimental.1
I'm running 2.6.35.14-97.fc14.x86_64 (i.e. Fedora 14)
The backtrace:
2013-05-06 15:53:41 foobar kernel: [1057700.540986] cp D 0000000000000000 0 18683 18670 0x00000000
2013-05-06 15:53:41 foobar kernel: [1057700.540989] ffff880018f5d438 0000000000000082 ffff880000000000 ffff88005ec245c0
2013-05-06 15:53:41 foobar kernel: [1057700.540991] 0000000000015540 0000000000015540 ffff880018f5dfd8 0000000000015540
2013-05-06 15:53:41 foobar kernel: [1057700.540994] 0000000000015540 0000000000015540 0000000000015540 ffff880018f5dfd8
2013-05-06 15:53:41 foobar kernel: [1057700.540996] Call Trace:
2013-05-06 15:53:41 foobar kernel: [1057700.540999] [<ffffffff81138b9b>] ? sync_buffer+0x0/0x2e
2013-05-06 15:53:41 foobar kernel: [1057700.541001] [<ffffffff81138b9b>] ? sync_buffer+0x0/0x2e
2013-05-06 15:53:41 foobar kernel: [1057700.541003] [<ffffffff81468b35>] io_schedule+0x48/0x63
2013-05-06 15:53:41 foobar kernel: [1057700.541005] [<ffffffff81138bc5>] sync_buffer+0x2a/0x2e
2013-05-06 15:53:41 foobar kernel: [1057700.541007] [<ffffffff814690dd>] __wait_on_bit+0x48/0x7b
2013-05-06 15:53:41 foobar kernel: [1057700.541010] [<ffffffff8146917e>] out_of_line_wait_on_bit+0x6e/0x79
2013-05-06 15:53:41 foobar kernel: [1057700.541012] [<ffffffff81138b9b>] ? sync_buffer+0x0/0x2e
2013-05-06 15:53:41 foobar kernel: [1057700.541014] [<ffffffff81066a44>] ? wake_bit_function+0x0/0x31
2013-05-06 15:53:41 foobar kernel: [1057700.541017] [<ffffffff81138b58>] __wait_on_buffer+0x24/0x26
2013-05-06 15:53:41 foobar kernel: [1057700.541019] [<ffffffff811abb14>] ext4_mb_init_cache+0x26b/0x55b
2013-05-06 15:53:41 foobar kernel: [1057700.541022] [<ffffffff811ac863>] ext4_mb_init_group+0xa3/0x20e
2013-05-06 15:53:41 foobar kernel: [1057700.541025] [<ffffffff811adc57>] ext4_mb_good_group+0x53/0xd6
2013-05-06 15:53:41 foobar kernel: [1057700.541028] [<ffffffff811ade0d>] ext4_mb_regular_allocator+0x133/0x281
2013-05-06 15:53:41 foobar kernel: [1057700.541031] [<ffffffff811aeb67>] ext4_mb_new_blocks+0x189/0x38c
2013-05-06 15:53:41 foobar kernel: [1057700.541033] [<ffffffff811a4bd6>] ? ext4_ext_find_extent+0x51/0x2b2
2013-05-06 15:53:41 foobar kernel: [1057700.541036] [<ffffffff811a7af9>] ext4_ext_map_blocks+0x15d1/0x186f
2013-05-06 15:53:41 foobar kernel: [1057700.541039] [<ffffffff812479a0>] ? alloc_iova+0x1cb/0x1dd
2013-05-06 15:53:41 foobar kernel: [1057700.541042] [<ffffffff810e7951>] ? zone_statistics+0x65/0x6a
2013-05-06 15:53:41 foobar kernel: [1057700.541044] [<ffffffff810da22f>] ? get_page_from_freelist+0x3fd/0x674
2013-05-06 15:53:41 foobar kernel: [1057700.541047] [<ffffffff8103c165>] ? need_resched+0x23/0x2d
2013-05-06 15:53:41 foobar kernel: [1057700.541050] [<ffffffff8118e2b4>] ext4_map_blocks+0x13b/0x21d
2013-05-06 15:53:41 foobar kernel: [1057700.541053] [<ffffffff8118e434>] _ext4_get_block+0x9e/0x126
2013-05-06 15:53:41 foobar kernel: [1057700.541055] [<ffffffff81137f3b>] ? attach_page_buffers+0x27/0x35
2013-05-06 15:53:41 foobar kernel: [1057700.541058] [<ffffffff8118e50c>] ext4_get_block+0x16/0x18
2013-05-06 15:53:41 foobar kernel: [1057700.541061] [<ffffffff8113a0fa>] __block_prepare_write+0x12e/0x28d
2013-05-06 15:53:41 foobar kernel: [1057700.541063] [<ffffffff8118e4f6>] ? ext4_get_block+0x0/0x18
2013-05-06 15:53:41 foobar kernel: [1057700.541066] [<ffffffff8113a319>] block_write_begin_newtrunc+0x80/0xc1
2013-05-06 15:53:41 foobar kernel: [1057700.541069] [<ffffffff8113a63f>] block_write_begin+0x38/0x71
2013-05-06 15:53:41 foobar kernel: [1057700.541071] [<ffffffff8118e4f6>] ? ext4_get_block+0x0/0x18
2013-05-06 15:53:41 foobar kernel: [1057700.541074] [<ffffffff8118f4f0>] ext4_write_begin+0x14d/0x22e
2013-05-06 15:53:41 foobar kernel: [1057700.541076] [<ffffffff8118e4f6>] ? ext4_get_block+0x0/0x18
2013-05-06 15:53:41 foobar kernel: [1057700.541079] [<ffffffff810d371f>] generic_file_buffered_write+0xfa/0x23d
2013-05-06 15:53:41 foobar kernel: [1057700.541081] [<ffffffff81190c8f>] ? ext4_dirty_inode+0x45/0x4a
2013-05-06 15:53:41 foobar kernel: [1057700.541084] [<ffffffff810d5184>] __generic_file_aio_write+0x24f/0x27f
2013-05-06 15:53:41 foobar kernel: [1057700.541086] [<ffffffff810d3e51>] ? find_get_page+0x49/0x6e
2013-05-06 15:53:41 foobar kernel: [1057700.541089] [<ffffffff8103c165>] ? need_resched+0x23/0x2d
2013-05-06 15:53:41 foobar kernel: [1057700.541091] [<ffffffff8103c165>] ? need_resched+0x23/0x2d
2013-05-06 15:53:41 foobar kernel: [1057700.541094] [<ffffffff810d520f>] generic_file_aio_write+0x5b/0xab
2013-05-06 15:53:41 foobar kernel: [1057700.541096] [<ffffffff81187b43>] ext4_file_write+0xa0/0xad
2013-05-06 15:53:41 foobar kernel: [1057700.541099] [<ffffffff8111752e>] do_sync_write+0xcb/0x108
2013-05-06 15:53:41 foobar kernel: [1057700.541102] [<ffffffff811dd241>] ? security_file_permission+0x16/0x18
2013-05-06 15:53:41 foobar kernel: [1057700.541105] [<ffffffff81117c08>] vfs_write+0xac/0x100
2013-05-06 15:53:41 foobar kernel: [1057700.541108] [<ffffffff81117e11>] sys_write+0x4a/0x6e
2013-05-06 15:53:41 foobar kernel: [1057700.541110] [<ffffffff81009cb2>] system_call_fastpath+0x16/0x1b
David
^ permalink raw reply [flat|nested] 3+ messages in thread
* Writing to a DM snapshot blocks for a long time
@ 2013-05-06 21:16 David Shaw
[not found] ` <alpine.DEB.2.10.1305072201090.13746@trent.utfs.org>
0 siblings, 1 reply; 3+ messages in thread
From: David Shaw @ 2013-05-06 21:16 UTC (permalink / raw)
To: ext3-users, dm-devel
Hello,
I'm seeing some odd behavior using DM snapshots, and I was hoping someone here could help shed some light on it. What I'm doing is creating a snapshot using DM directly (not through LVM), mounting the snapshot, and then writing to both sides (the mounted snapshot as well as the original filesystem). The data written to the snapshot goes away after I tear it down, of course.
I managed to get this down to a simple reproduction case. All this is starting with a LVM VG named "tests", which contains two LVs named "original" and "cow". The "original" LV is formatted ext4 and mounted on /original.
1) time dd if=/dev/zero bs=16384 count=1 of=/original/zeroes
2) dmsetup suspend tests-original
3) dmsetup table tests-original | dmsetup create tests-original-backup
4) echo 0 `blockdev --getsz /dev/mapper/tests-original` snapshot-origin /dev/mapper/tests-original-backup | dmsetup reload tests-original
5) echo 0 `blockdev --getsz /dev/mapper/tests-original-backup` snapshot /dev/mapper/tests-original-backup /dev/mapper/tests-cow N 1024 | dmsetup create tests-snap
6) dmsetup resume tests-original
7) mount /dev/mapper/tests-snap /snap
So far so good - original is mounted on /original, the snapshot is mounted on /snap. Now here comes the problem:
8) time dd if=/dev/zero bs=16384 count=1 of=/snap/zeroes
Writing to the snapshot blocks for a long time (60-180 seconds). Doing a strace of the dd shows it blocking in write(). Note that /snap/zeroes is overwriting (the snapshot version of) the /original/zeroes file written in step 1. If this isn't an overwrite (if, for example, the dd wrote to "/snap/a-different-filename"), there is no blocking. Similarly, there is no problem writing to anything under "/original".
Test cleanup steps that work without any problem:
9) umount /snap
10) dmsetup suspend tests-original
11) dmsetup table tests-original-backup | dmsetup reload tests-original
12) dmsetup remove tests-snap
13) dmsetup resume tests-original
14) dmsetup remove tests-original-backup
The kernel in question is kernel-PAE-2.6.35.14-97.fc14.i686 (i.e. Fedora 14). It's running on a Dell R410 with 16 gigs of RAM. The PV the VG resides on is a 4-disk RAID5 using the Dell PERC 6 RAID card (from the LVM perspective, it just sees a single block device from the card here).
I captured this trace (via 'echo t > /proc/sysrq-trigger') of a cp stuck in write() while writing to the snapshot:
2013-05-06 15:53:41 foobar kernel: [1057700.540986] cp D 0000000000000000 0 18683 18670 0x00000000
2013-05-06 15:53:41 foobar kernel: [1057700.540989] ffff880018f5d438 0000000000000082 ffff880000000000 ffff88005ec245c0
2013-05-06 15:53:41 foobar kernel: [1057700.540991] 0000000000015540 0000000000015540 ffff880018f5dfd8 0000000000015540
2013-05-06 15:53:41 foobar kernel: [1057700.540994] 0000000000015540 0000000000015540 0000000000015540 ffff880018f5dfd8
2013-05-06 15:53:41 foobar kernel: [1057700.540996] Call Trace:
2013-05-06 15:53:41 foobar kernel: [1057700.540999] [<ffffffff81138b9b>] ? sync_buffer+0x0/0x2e
2013-05-06 15:53:41 foobar kernel: [1057700.541001] [<ffffffff81138b9b>] ? sync_buffer+0x0/0x2e
2013-05-06 15:53:41 foobar kernel: [1057700.541003] [<ffffffff81468b35>] io_schedule+0x48/0x63
2013-05-06 15:53:41 foobar kernel: [1057700.541005] [<ffffffff81138bc5>] sync_buffer+0x2a/0x2e
2013-05-06 15:53:41 foobar kernel: [1057700.541007] [<ffffffff814690dd>] __wait_on_bit+0x48/0x7b
2013-05-06 15:53:41 foobar kernel: [1057700.541010] [<ffffffff8146917e>] out_of_line_wait_on_bit+0x6e/0x79
2013-05-06 15:53:41 foobar kernel: [1057700.541012] [<ffffffff81138b9b>] ? sync_buffer+0x0/0x2e
2013-05-06 15:53:41 foobar kernel: [1057700.541014] [<ffffffff81066a44>] ? wake_bit_function+0x0/0x31
2013-05-06 15:53:41 foobar kernel: [1057700.541017] [<ffffffff81138b58>] __wait_on_buffer+0x24/0x26
2013-05-06 15:53:41 foobar kernel: [1057700.541019] [<ffffffff811abb14>] ext4_mb_init_cache+0x26b/0x55b
2013-05-06 15:53:41 foobar kernel: [1057700.541022] [<ffffffff811ac863>] ext4_mb_init_group+0xa3/0x20e
2013-05-06 15:53:41 foobar kernel: [1057700.541025] [<ffffffff811adc57>] ext4_mb_good_group+0x53/0xd6
2013-05-06 15:53:41 foobar kernel: [1057700.541028] [<ffffffff811ade0d>] ext4_mb_regular_allocator+0x133/0x281
2013-05-06 15:53:41 foobar kernel: [1057700.541031] [<ffffffff811aeb67>] ext4_mb_new_blocks+0x189/0x38c
2013-05-06 15:53:41 foobar kernel: [1057700.541033] [<ffffffff811a4bd6>] ? ext4_ext_find_extent+0x51/0x2b2
2013-05-06 15:53:41 foobar kernel: [1057700.541036] [<ffffffff811a7af9>] ext4_ext_map_blocks+0x15d1/0x186f
2013-05-06 15:53:41 foobar kernel: [1057700.541039] [<ffffffff812479a0>] ? alloc_iova+0x1cb/0x1dd
2013-05-06 15:53:41 foobar kernel: [1057700.541042] [<ffffffff810e7951>] ? zone_statistics+0x65/0x6a
2013-05-06 15:53:41 foobar kernel: [1057700.541044] [<ffffffff810da22f>] ? get_page_from_freelist+0x3fd/0x674
2013-05-06 15:53:41 foobar kernel: [1057700.541047] [<ffffffff8103c165>] ? need_resched+0x23/0x2d
2013-05-06 15:53:41 foobar kernel: [1057700.541050] [<ffffffff8118e2b4>] ext4_map_blocks+0x13b/0x21d
2013-05-06 15:53:41 foobar kernel: [1057700.541053] [<ffffffff8118e434>] _ext4_get_block+0x9e/0x126
2013-05-06 15:53:41 foobar kernel: [1057700.541055] [<ffffffff81137f3b>] ? attach_page_buffers+0x27/0x35
2013-05-06 15:53:41 foobar kernel: [1057700.541058] [<ffffffff8118e50c>] ext4_get_block+0x16/0x18
2013-05-06 15:53:41 foobar kernel: [1057700.541061] [<ffffffff8113a0fa>] __block_prepare_write+0x12e/0x28d
2013-05-06 15:53:41 foobar kernel: [1057700.541063] [<ffffffff8118e4f6>] ? ext4_get_block+0x0/0x18
2013-05-06 15:53:41 foobar kernel: [1057700.541066] [<ffffffff8113a319>] block_write_begin_newtrunc+0x80/0xc1
2013-05-06 15:53:41 foobar kernel: [1057700.541069] [<ffffffff8113a63f>] block_write_begin+0x38/0x71
2013-05-06 15:53:41 foobar kernel: [1057700.541071] [<ffffffff8118e4f6>] ? ext4_get_block+0x0/0x18
2013-05-06 15:53:41 foobar kernel: [1057700.541074] [<ffffffff8118f4f0>] ext4_write_begin+0x14d/0x22e
2013-05-06 15:53:41 foobar kernel: [1057700.541076] [<ffffffff8118e4f6>] ? ext4_get_block+0x0/0x18
2013-05-06 15:53:41 foobar kernel: [1057700.541079] [<ffffffff810d371f>] generic_file_buffered_write+0xfa/0x23d
2013-05-06 15:53:41 foobar kernel: [1057700.541081] [<ffffffff81190c8f>] ? ext4_dirty_inode+0x45/0x4a
2013-05-06 15:53:41 foobar kernel: [1057700.541084] [<ffffffff810d5184>] __generic_file_aio_write+0x24f/0x27f
2013-05-06 15:53:41 foobar kernel: [1057700.541086] [<ffffffff810d3e51>] ? find_get_page+0x49/0x6e
2013-05-06 15:53:41 foobar kernel: [1057700.541089] [<ffffffff8103c165>] ? need_resched+0x23/0x2d
2013-05-06 15:53:41 foobar kernel: [1057700.541091] [<ffffffff8103c165>] ? need_resched+0x23/0x2d
2013-05-06 15:53:41 foobar kernel: [1057700.541094] [<ffffffff810d520f>] generic_file_aio_write+0x5b/0xab
2013-05-06 15:53:41 foobar kernel: [1057700.541096] [<ffffffff81187b43>] ext4_file_write+0xa0/0xad
2013-05-06 15:53:41 foobar kernel: [1057700.541099] [<ffffffff8111752e>] do_sync_write+0xcb/0x108
2013-05-06 15:53:41 foobar kernel: [1057700.541102] [<ffffffff811dd241>] ? security_file_permission+0x16/0x18
2013-05-06 15:53:41 foobar kernel: [1057700.541105] [<ffffffff81117c08>] vfs_write+0xac/0x100
2013-05-06 15:53:41 foobar kernel: [1057700.541108] [<ffffffff81117e11>] sys_write+0x4a/0x6e
2013-05-06 15:53:41 foobar kernel: [1057700.541110] [<ffffffff81009cb2>] system_call_fastpath+0x16/0x1b
Any advice would be very much appreciated.
David
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-05-08 17:07 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-08-16 17:55 Writing to a DM snapshot blocks for a long time David Shaw
2013-05-06 21:16 David Shaw
[not found] ` <alpine.DEB.2.10.1305072201090.13746@trent.utfs.org>
2013-05-08 17:07 ` David Shaw
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.