[LU-10938] Metadata writeback cache support Created: 22/Apr/18 Updated: 06/Dec/22 |
|
| Status: | Open |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major |
| Reporter: | Oleg Drokin | Assignee: | Qian Yingjin |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Sub-Tasks: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Epic/Theme: | Performance | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
Metadata writeback cache is a highly desirable feature that should allow Lustre to overcome link latency for modifying metadata operations esp. noticeable in interactive type of workloads. Examples include upacking large archives and building software on a single node with no contention from any other nodes. Another highly visible set of usecases would include "File/directory-per-process" kind of benchmarks like say mdtest. |
| Comments |
| Comment by Gerrit Updater [ 23/Apr/18 ] |
|
Oleg Drokin (oleg.drokin@intel.com) uploaded a new patch: https://review.whamcloud.com/32128 |
| Comment by Gerrit Updater [ 23/Apr/18 ] |
|
Oleg Drokin (oleg.drokin@intel.com) uploaded a new patch: https://review.whamcloud.com/32126 |
| Comment by Gerrit Updater [ 23/Apr/18 ] |
|
Oleg Drokin (oleg.drokin@intel.com) uploaded a new patch: https://review.whamcloud.com/32124 |
| Comment by Gerrit Updater [ 23/Apr/18 ] |
|
Oleg Drokin (oleg.drokin@intel.com) uploaded a new patch: https://review.whamcloud.com/32116 |
| Comment by Gerrit Updater [ 23/Apr/18 ] |
|
Oleg Drokin (oleg.drokin@intel.com) uploaded a new patch: https://review.whamcloud.com/32127 |
| Comment by Gerrit Updater [ 23/Apr/18 ] |
|
Oleg Drokin (oleg.drokin@intel.com) uploaded a new patch: https://review.whamcloud.com/32121 |
| Comment by Gerrit Updater [ 23/Apr/18 ] |
|
Oleg Drokin (oleg.drokin@intel.com) uploaded a new patch: https://review.whamcloud.com/32119 |
| Comment by Gerrit Updater [ 23/Apr/18 ] |
|
Oleg Drokin (oleg.drokin@intel.com) uploaded a new patch: https://review.whamcloud.com/32118 |
| Comment by Gerrit Updater [ 23/Apr/18 ] |
|
Oleg Drokin (oleg.drokin@intel.com) uploaded a new patch: https://review.whamcloud.com/32117 |
| Comment by Gerrit Updater [ 23/Apr/18 ] |
|
Oleg Drokin (oleg.drokin@intel.com) uploaded a new patch: https://review.whamcloud.com/32120 |
| Comment by Gerrit Updater [ 23/Apr/18 ] |
|
Oleg Drokin (oleg.drokin@intel.com) uploaded a new patch: https://review.whamcloud.com/32125 |
| Comment by Gerrit Updater [ 23/Apr/18 ] |
|
Oleg Drokin (oleg.drokin@intel.com) uploaded a new patch: https://review.whamcloud.com/32123 |
| Comment by Gerrit Updater [ 23/Apr/18 ] |
|
Oleg Drokin (oleg.drokin@intel.com) uploaded a new patch: https://review.whamcloud.com/32122 |
| Comment by Patrick Farrell (Inactive) [ 01/May/18 ] |
|
Oleg, This is a bit of a silly question, but I don't know the answer in Gerrit. How can I get the full patch series in to my local git/how can I tell what the order is so I can find the last one to check out? Thanks |
| Comment by Oleg Drokin [ 02/May/18 ] |
|
the tip of the tree is this patch: https://review.whamcloud.com/#/c/32128/3 - you know this by looking in the right top part of that page titled "related changes" and seeing it's at the very top of the list. So if you checkout this patch (download -> checkout) - you'll get this patch and everything else it's based upon |
| Comment by Gerrit Updater [ 02/May/18 ] |
|
Oleg Drokin (oleg.drokin@intel.com) uploaded a new patch: https://review.whamcloud.com/32241 |
| Comment by Patrick Farrell (Inactive) [ 02/May/18 ] |
|
Thanks! I'll probably figure this out, but is there any particular trick to turning this on? Will it happen automatically if I make a new directory and start creating stuff in it? |
| Comment by Oleg Drokin [ 02/May/18 ] |
|
yes, current code asumes you start from an mkdir, the resulting directory will have wbc fully enabled (there's a bit of a bug that if you delete the directory then create another with the same name - wbc would not turn on, I need to track it down some day). |
| Comment by Patrick Farrell (Inactive) [ 02/May/18 ] |
|
Perfect. Just observed that myself. Thank you, nice and easy to test. |
| Comment by Gerrit Updater [ 29/May/18 ] |
|
Oleg Drokin (oleg.drokin@intel.com) merged in patch https://review.whamcloud.com/32241/ |
| Comment by Andreas Dilger [ 03/Jul/19 ] |
|
One thought I had was whether it is possible to cache/merge setattr-like requests like utimensat(), fchmod(), fchown(), fchgrp(), etc. on the client when creating/writing DoM regular files on the client? The client should already have a write lock on the file for DoM write, and the MDS shouldn't care whether the time, mode, permission, and maybe UID/GID changes before the file is written to the MDS because these attributes should all be sent with the write request. |
| Comment by Patrick Farrell (Inactive) [ 04/Jul/19 ] |
|
I should perhaps know the answer to this question, but which Lustre attributes are exclusively on the MDS? Permissions are, xattrs are, and size is not (even in DOM, it's pulled from the data object - it's just that object is on the MDS) but what about the various time properties? The issue that will come up, I think, is which bits the client has a write lock on. |
| Comment by Andreas Dilger [ 04/Jul/19 ] |
|
The timestamps belong to the target that has the most recent ctime, but in any case since this optimization would be useful mostly for DoM files, the MDS would own all of the attributes including the size, as long as the later components were not initialized. Even if the later components were initialized, setting the timestamps, UID, GID, permission, etc. could be cached on the client as long as it has the DoM write lock on the MDT inode, since no other clients could modify/access these attributes. |
| Comment by Nathan Rutman [ 05/Jul/19 ] |
|
Status of the prototype, per ISC
|
| Comment by Qian Yingjin [ 13/Jul/19 ] |
|
After reading the code, I found that current WBC still need to solve the following problem of reopen the file:
|
| Comment by Qian Yingjin [ 02/Sep/19 ] |
|
I will try to rebase all WBC patches against master branch. |
| Comment by Patrick Farrell (Inactive) [ 02/Sep/19 ] |
|
I would strongly prefer not merging them. Having them broken out like this is really nice. |
| Comment by Gerrit Updater [ 25/Nov/19 ] |
|
Yingjin Qian (qian@ddn.com) uploaded a new patch: https://review.whamcloud.com/36851 |
| Comment by Gerrit Updater [ 27/Dec/19 ] |
|
Yingjin Qian (qian@ddn.com) uploaded a new patch: https://review.whamcloud.com/37104 |