[LU-11025] DNE3: directory restripe Created: 16/May/18 Updated: 21/Nov/23 Due: 16/Dec/18 Resolved: 17/Feb/21 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.11.0 |
| Fix Version/s: | Lustre 2.14.0 |
| Type: | New Feature | Priority: | Major |
| Reporter: | Lai Siyao | Assignee: | Lai Siyao |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | dne3 | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Epic/Theme: | dne3 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
In DNE system, MDTs are likely to become imbalanced over time, and user may also add/remove MDTs. So there is a need to move load from one MDT to anothe, this is what dir restripe can do. Directory restripe should meet below requirements:
Functional spec:
|
| Comments |
| Comment by Andreas Dilger [ 16/May/18 ] |
Could you please describe this approach more completely? Let's say we pick an arbitrary upper limit of LMV_MAX_STRIPE_COUNT = 256 stripes per directory (which seems quite reasonable). The client computes idx = hash(name) % LMV_MAX_STRIPE_COUNT to get an idx value 0, 255, and what does it do with idx after this? If there is a single shard, idx is irrelevant, and the file goes on the master MDT. If the directory doubles in size and there are now 1+1= 2 shards, then the hash is split into 2 parts 0, 127 and 128, 255 and put onto the 2 shards, moving 1/2 of the existing entries to the new shard? If directory doubles in size again and there are 2+2=4 shards, then the hash is split into 4 parts 0, 63, 64, 127, 128, 191, 192, 255 and put onto the 4 shards, again moving 1/2 of each existing shard onto the new shards? If we assume that a growing directory will average about 3/4 full shards at any time (i.e. half way between previous split and next split), then it will have on average 2/3 remote entries (migrated to the shard when it was split) and 1/3 local entries (created locally after the shard was split). |
| Comment by Lai Siyao [ 17/May/18 ] |
|
Yes, it's just like what you described. So we track the usage of directory, if it's growing fast, then we split stripe fast, so that it can reach max stripes (MDT count, or a limit we set in the beginning) soon. This may be able to avoid too much remote objects, but if a directory is not growing fast, and it's becoming large over long time, it will contain 2/3 remote objects like your described. |
| Comment by Lai Siyao [ 17/May/18 ] |
|
And if the system doesn't need to support NFS on Lustre, there should be an option to allow restripe move both inode and dirent upon stripe split. |
| Comment by Gerrit Updater [ 18/Nov/19 ] |
|
Lai Siyao (lai.siyao@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/36774 |
| Comment by Gerrit Updater [ 18/Nov/19 ] |
|
Lai Siyao (lai.siyao@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/36775 |
| Comment by Gerrit Updater [ 26/Nov/19 ] |
|
Lai Siyao (lai.siyao@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/36864 |
| Comment by Gerrit Updater [ 26/Nov/19 ] |
|
Lai Siyao (lai.siyao@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/36865 |
| Comment by Gerrit Updater [ 30/Nov/19 ] |
|
Lai Siyao (lai.siyao@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/36898 |
| Comment by Gerrit Updater [ 14/Dec/19 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/36774/ |
| Comment by Gerrit Updater [ 20/Jan/20 ] |
|
Lai Siyao (lai.siyao@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/37281 |
| Comment by Gerrit Updater [ 20/Jan/20 ] |
|
Lai Siyao (lai.siyao@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/37282 |
| Comment by Gerrit Updater [ 20/Jan/20 ] |
|
Lai Siyao (lai.siyao@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/37283 |
| Comment by Gerrit Updater [ 20/Jan/20 ] |
|
Lai Siyao (lai.siyao@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/37284 |
| Comment by Gerrit Updater [ 20/Feb/20 ] |
|
Lai Siyao (lai.siyao@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/37634 |
| Comment by Gerrit Updater [ 25/Feb/20 ] |
|
Lai Siyao (lai.siyao@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/37711 |
| Comment by Gerrit Updater [ 25/Feb/20 ] |
|
Lai Siyao (lai.siyao@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/37712 |
| Comment by Gerrit Updater [ 25/Feb/20 ] |
|
Lai Siyao (lai.siyao@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/37713 |
| Comment by Gerrit Updater [ 27/Feb/20 ] |
|
Lai Siyao (lai.siyao@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/37752 |
| Comment by Gerrit Updater [ 29/Mar/20 ] |
|
Lai Siyao (lai.siyao@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/38097 |
| Comment by Gerrit Updater [ 31/Mar/20 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/36775/ |
| Comment by Gerrit Updater [ 31/Mar/20 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/37634/ |
| Comment by Gerrit Updater [ 31/Mar/20 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/37711/ |
| Comment by Gerrit Updater [ 01/Apr/20 ] |
|
Andreas Dilger (adilger@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/38107 |
| Comment by Gerrit Updater [ 03/Apr/20 ] |
|
Lai Siyao (lai.siyao@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/38135 |
| Comment by Gerrit Updater [ 14/Apr/20 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/38107/ |
| Comment by Gerrit Updater [ 15/Apr/20 ] |
|
Lai Siyao (lai.siyao@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/38232 |
| Comment by Gerrit Updater [ 15/Apr/20 ] |
|
Lai Siyao (lai.siyao@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/38233 |
| Comment by Gerrit Updater [ 20/Apr/20 ] |
|
Lai Siyao (lai.siyao@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/38285 |
| Comment by Gerrit Updater [ 23/Apr/20 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/37712/ |
| Comment by Gerrit Updater [ 07/May/20 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/36865/ |
| Comment by Gerrit Updater [ 07/May/20 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/37281/ |
| Comment by Gerrit Updater [ 07/May/20 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/38232/ |
| Comment by Gerrit Updater [ 20/May/20 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/37282/ |
| Comment by Gerrit Updater [ 20/May/20 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/38097/ |
| Comment by Gerrit Updater [ 20/May/20 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/36898/ |
| Comment by Andreas Dilger [ 20/May/20 ] |
|
Lai, I think it makes sense to move the FIDMAP patches over to their own LU ticket. I don't think that this functionality is critical for 2.14, and it will simplify their tracking. I don't think that DNE directory auto-split will move all of the inodes by default, only the directory entries, and FIDMAP is only needed in the case of inode migration (which should not be the default). |
| Comment by Gerrit Updater [ 02/Jun/20 ] |
|
Lai Siyao (lai.siyao@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/38801 |
| Comment by Gerrit Updater [ 02/Jun/20 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/37284/ |
| Comment by Gerrit Updater [ 11/Jun/20 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/38801/ |