[LU-10190] Agent object for cross-MDTs reference

• Type: Technical task
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.11.0
• Assignee: nasf (Inactive)
• Reporter: nasf (Inactive)

Description

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'.

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.

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.

Comments

[Peter Jones]

Landed for 2.11

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/28855/
Subject: LU-10190 osd-zfs: create agent object for remote object
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: c0a455e6d035c3ce4f9d52395b0a77773b2fac93

[nasf (Inactive)]

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.

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.

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.

[nasf (Inactive)]

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.

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.