PCC Phase 2
(LU-12714)
|
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | Lustre 2.13.0 |
| Type: | Technical task | Priority: | Minor |
| Reporter: | Qian Yingjin | Assignee: | Qian Yingjin |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Rank (Obsolete): | 9223372036854775807 |
| Description |
|
PCC uses the layout lock to protect the cache validity. Currently PCC only supports auto attach at the next open. However, the layout lock can be revoked at any time by LRU/manual lock shrinking or lock conflict callback. For example, the layout lock can be revoked when perform I/Os after open the file. At this time, the cached file will be detached involuntary. The I/O originally directed into PCC will redirect to OSTs after the data restore into OSTs' objects. This cost of this unwilling behavior may be expensive. To avoid this problem, it is necessary to implement auto attach for PCC even during IOs (not only at the open time). And auto attach should be enabled by default. |
| Comments |
| Comment by Patrick Farrell (Inactive) [ 09/Jul/19 ] |
|
I thought Oleg's suggestion was for the PCC case to hold the layout lock during I/O - Is that not practical? |
| Comment by Qian Yingjin [ 09/Jul/19 ] |
|
Currently the layout locks are maintained in a LRU way. They can be shrinking at any time according to the client or server lock load... If keep holding the layout lock during I/O like the lease lock (not in lock LRU list), even only for PCC case, it may cause many locks caching on the clients and servers, which will result in memory pressure. |
| Comment by Qian Yingjin [ 09/Jul/19 ] |
|
And Current problem is that many other ibits locks (PERM and UPDATE) are binding with the layout lock. The can cancellation of other ibits lock may revoke the layout lock also. |
| Comment by Patrick Farrell (Inactive) [ 09/Jul/19 ] |
|
Hmm, but I'm basically just suggesting you hold it during I/O. Not all the time. If you're doing I/O to a file, it's not unreasonable to have a lock on it nor is it wasteful of memory. In order to do I/O in the normal Lustre path, you have to take the layout lock for read before doing I/O. You don't hold it across the I/O (and you can't do so safely because your I/O might cause layout changes, requiring the lock). But PCC doesn't cause those kinds of layout changes (which are FLR/PFL layout updates, basically), I think? So you could take the layout lock for read before I/O, and hold it across I/O. If the other bits conflict, then the lock will be cancelled once your I/O is over, and you will ask for a new lock on the next I/O, with just the layout bit in it. You will have to be careful about it, but it seems simpler than implementing attach during I/O. Maybe I am wrong - I can't see how attach during I/O would work, but I assume you have a plan. Perhaps it is simpler than it sounds? |
| Comment by Gerrit Updater [ 11/Jul/19 ] |
|
Yingjin Qian (qian@ddn.com) uploaded a new patch: https://review.whamcloud.com/35468 |
| Comment by Qian Yingjin [ 11/Jul/19 ] |
|
Hi Patrick, Implementing attach during IO is not very hard, please see the patch above. |
| Comment by Gerrit Updater [ 30/Aug/19 ] |
|
Yingjin Qian (qian@ddn.com) uploaded a new patch: https://review.whamcloud.com/36005 |
| Comment by Gerrit Updater [ 27/Oct/19 ] |
|
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/36005/ |
| Comment by Peter Jones [ 27/Oct/19 ] |
|
Landed for 2.13 |
[LU-12526]