Bug #10958
librbd: fsx detected invalid object map after resize without object map enabled
0%
Description
2015-02-25T22:08:02.276 INFO:teuthology.orchestra.run.burnupi56.stdout:1353 trunc from 0xbc59c14 to 0x871e069 2015-02-25T22:08:03.692 INFO:teuthology.orchestra.run.burnupi56.stdout:1354 read 0x6ebf4eb thru 0x6ecb398 (0xbeae bytes) 2015-02-25T22:08:03.692 INFO:teuthology.orchestra.run.burnupi56.stdout:1357 clone 13 order 23 su 262144 sc 3 2015-02-25T22:08:04.719 INFO:teuthology.orchestra.run.burnupi56.stdout:truncating image image_client.0-clone12 from 0x871e069 (overlap 0x36f6bb2) to 0x1b7b5d9 2015-02-25T22:08:05.529 INFO:teuthology.orchestra.run.burnupi56.stdout:checking clone #11, image image_client.0-clone11 against file /home/ubuntu/cephtest/archive/fsx-image_client.0-parent12 2015-02-25T22:08:06.399 INFO:teuthology.orchestra.run.burnupi56.stdout:1358 read 0x14af9e2 thru 0x14b2b06 (0x3125 bytes) 2015-02-25T22:08:06.408 INFO:teuthology.orchestra.run.burnupi56.stdout:1359 write 0x518fe88 thru 0x51941b0 (0x4329 bytes) 2015-02-25T22:08:06.682 INFO:teuthology.orchestra.run.burnupi56.stdout:1361 read 0x4655c96 thru 0x465b077 (0x53e2 bytes) 2015-02-25T22:08:06.707 INFO:teuthology.orchestra.run.burnupi56.stdout:1362 trunc from 0x871e069 to 0x1f71f18 2015-02-25T22:08:07.225 INFO:teuthology.orchestra.run.burnupi56.stdout:rbd_get_flags() indicates object map is invalid 2015-02-25T22:08:07.225 INFO:teuthology.orchestra.run.burnupi56.stdout:dotruncate: ops->resize: Invalid argument
Note that ceph.conf has copy on read enabled, as well as small amounts of messenger failure injection, but it's just using the default rbd features, which do not include object map.
This doesn't seem to reproduce easily.
Associated revisions
librbd: moved flush / cache invalidate to resize state machine
Keep async_resize truly async by moving flush and invalidate cache
operations to individual states within the resize state machine.
Fixes: #10958
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
History
#1 Updated by Jason Dillaman about 9 years ago
- Status changed from New to In Progress
- Assignee set to Jason Dillaman
#2 Updated by Jason Dillaman about 9 years ago
The AIO flush was removed during the lock updates. However, it really should have been in a AsyncResizeRequest state instead of within the async_resize method.
#3 Updated by Josh Durgin about 9 years ago
Seems like we still want it before invalidating the cache though?
#4 Updated by Jason Dillaman about 9 years ago
- Status changed from In Progress to Fix Under Review
#5 Updated by Jason Dillaman about 9 years ago
Josh Durgin wrote:
Seems like we still want it before invalidating the cache though?
Agreed -- I moved both flush_async_operations and invalidate_cache to the resize state machine.
#6 Updated by Jason Dillaman about 9 years ago
#7 Updated by Jason Dillaman about 9 years ago
- Status changed from Fix Under Review to Resolved