https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-10190 Lustre <p>In DNE environment, the object and its name entry may reside on different MDTs. Under such case, we will create an agent object on the MDT where the name entry resides. The agent object is empty to indicates that the real object for this name entry resides on another MDT. If without agent object, related name entry will be skipped when perform MDT side file level backup/restore via ZPL by userspace tool, such as 'tar'.</p> <p>ldiskfs supports agent object. After migrated to ZFS, the agent object will be on ZFS backend. ZFS needs to handle it to avoid leak. So supporting agent object is necessary if want to backup/restore ZFS via ZPL, or migrate ZFS to ldiskfs.</p> <p>On the other hand, although ldiskfs supports agent object, but for regular-file, too much agent objects is not a good solution. We will consider to share agent object for multiple remote reference case.</p> LU-10190

Agent object for cross-MDTs reference

Technical task LU-7585 Minor Resolved Fixed nasf nasf Thu, 2 Nov 2017 01:18:59 +0000 Sun, 17 Dec 2017 16:08:20 +0000 Sun, 17 Dec 2017 16:08:20 +0000 Lustre 2.11.0 0 2 <blockquote> <p>On the other hand, although ldiskfs supports agent object, but for regular-file, too much agent objects is not a good solution. We will consider to share agent object for multiple remote reference case.</p></blockquote> <p>One issue about the solution of multiple remote entries sharing the same agent object is that we have to depend on the FID-in-dirent to locate remote object. But the FID-in-dirent will be lost after server side file-level backup/restore. Then before the namespace LFSCK rebuild the FID-in-dirent, we have no way to access such remote object via namespace. That breaks the requirement that the system should be accessible during LFSCK.</p> <p>Another optimization should be done is for ZFS backend. Currently, we have to lookup the entry with the given name to be removed for dir_delete operation. Because we do not know whether the given name is for a cross-MDTs reference or not. If yes, we need to destroy related agent object to avoid leak. But for local reference case, such lookup is useless. To avoid the overhead, we need some better solution.</p> <p>One possible solution is that, we can enhance the dt_delete() API to pass related object's FID information to the OSD, then the OSD can know whether need to handle agent object or not.</p> <p>On the other hand, since ZFS needs to lookup the entry with the given name (to be removed) for zap_remove, is it possible to enhance related API to allow ZFS to remove the given entry directly? That means to move the ZFS internal lookup to Lustre OSD, just like ldiskfs backend does.</p> <p>Oleg Drokin (oleg.drokin@intel.com) merged in patch <a href="https://review.whamcloud.com/28855/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/28855/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-10190" title="Agent object for cross-MDTs reference" class="issue-link" data-issue-key="LU-10190"><del>LU-10190</del></a> osd-zfs: create agent object for remote object<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: c0a455e6d035c3ce4f9d52395b0a77773b2fac93</p> <p>Landed for 2.11</p> Development Rank 1|hzzmzz: Rank (Obsolete) 9223372036854775807