Project

General

Profile

Actions

Feature #8088

closed

Make FileStore::_do_copy_range use fiemap

Added by Haomai Wang about 10 years ago. Updated about 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
OSD
Target version:
% Done:

0%

Source:
other
Tags:
Backport:
Reviewed:
Affected Versions:
Pull request ID:

Description

In rbd usage, a large volume which has lots of objects will be in a low performance during a long time after creating a snapshot.

The main reason is FileStore::_clone occur a lot of time. According to my statistic:
_do_op sum: 20041719 avg: 55671 count: 360 max: 161553 min: 447
_do_transactions sum: 19967933 avg: 55466 count: 360 max: 161543 min: 438
_do_transaction sum: 19981841 avg: 27752 count: 720 max: 159789 min: 154
_write sum: 311767 avg: 866 count: 360 max: 36754 min: 72
_clone sum: 19084627 avg: 82976 count: 230 max: 159373 min: 50467
lfn_open sum: 179185 avg: 69 count: 2578 max: 45273 min: 17
_do_copy_range sum: 5313792 avg: 23306 count: 228 max: 69037 min: 7037
write_fd sum: 1541552 avg: 2458 count: 627 max: 40312 min: 8
safe_write sum: 837150 avg: 120 count: 6959 max: 7348 min: 6
clone sum: 262197 avg: 1149 count: 228 max: 32680 min: 97
_fgetattrs sum: 808860 avg: 3547 count: 228 max: 31114 min: 155
_fsetattrs sum: 85561 avg: 72 count: 1178 max: 11899 min: 24
_set_replay_guard sum: 12516463 avg: 54419 count: 230 max: 82226 min: 14846

_do_copy_range is a reason. It will read a entire object and write to although this object maybe only has some data in the end of object.
This case will happen in rbd usage.

So maybe we can use fiemap to do sparse_write.

Actions #2

Updated by Haomai Wang about 10 years ago

It can also reduce the consuming time of "_set_replay_guard", because "_set_replay_guard" has two fsync which are affected by the bytes of write.

Actions #4

Updated by Haomai Wang about 10 years ago

  • Status changed from New to Closed
Actions

Also available in: Atom PDF