[LU-11376] Special file/dir to represent DAOS Containers Created: 14/Sep/18  Updated: 10/Jan/24  Resolved: 08/May/19

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: None
Fix Version/s: Lustre 2.13.0

Type: New Feature Priority: Minor
Reporter: Johann Lombardi Assignee: Bruno Faccini (Inactive)
Resolution: Fixed Votes: 0
Labels: patch

Attachments: Microsoft PowerPoint Lombardi_Intel_Cross_tier_unified_namespace_v3.pptx    
Issue Links:
Related
is related to LU-7207 HSM: Add Archive UUID to delete chang... Open
is related to LU-12104 SEGV during "lfs find [--mdt-count=[+... Resolved
is related to LUDOC-465 Add feature documentation for foreign... Resolved
is related to LU-10606 HSM info as part of LOV layout xattr Open
is related to LU-12682 foreign LOV/LMV format usage implemen... Resolved
Rank (Obsolete): 9223372036854775807

 Description   

Add support for a new extended attribute or special file/dir layout to represent in the Lustre namespace an external DAOS container identified by a UUID. The pro’s and con’s of both options will be presented at the LAD’18 and summarized in this ticket.

The purpose of this ticket is to track the effort to implement this feature.



 Comments   
Comment by Nathan Rutman [ 27/Sep/18 ]

Special layout please, able to specify an arbitrary external reference. See LU-10606.

Comment by Gerrit Updater [ 29/Nov/18 ]

Faccini Bruno (bruno.faccini@intel.com) uploaded a new patch: https://review.whamcloud.com/33755
Subject: LU-11376 lov: new foreign LOV format
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 7b0a57a27e291cef71b7af0be6150ae0a3224189

Comment by Bruno Faccini (Inactive) [ 30/Nov/18 ]

Gerrit change #33755 is a patch to allow for a file's flexible LOV format that will permit to specify an arbitrary external reference for a file. The idea behind this is to provide Lustre namespace support and LOV prefetch/caching under layout-lock protection, for user-land/external usage.

 

 

Comment by Gerrit Updater [ 22/Jan/19 ]

Faccini Bruno (bruno.faccini@intel.com) uploaded a new patch: https://review.whamcloud.com/34087
Subject: LU-11376 lmv: new foreign LMV format
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 63ee0812223af72c39df776c7930dbb9cf791595

Comment by Bruno Faccini (Inactive) [ 22/Jan/19 ]

Gerrit change #34087 is a patch to allow for a dir's flexible LMV format that will permit to specify an arbitrary external reference for a dir. The idea behind this is to provide Lustre namespace support and LMV prefetch/caching under lock protection, for user-land/external usage.

 

Comment by Nathan Rutman [ 25/Jan/19 ]
/* foreign LMV EA */
struct lmv_foreign_md {
	__u32 lfm_magic;	/* magic number = LOV_MAGIC_FOREIGN */
	__u32 lfm_length;	/* length of lfm_value */
	char lfm_value[];
};

Can we add fields here for __u32 lfm_type and __u32 lfm_flags so that Lustre can in the future have some way of understanding the contents? If everything is hidden inside lfm_value, then Lustre would have no way of, for example:

  • selecting a client-side handler/upcall for different foreign types
  • selecting a server-side handler of any type
  • invoking the HSM mechanisms to automatically populate/swap-in a file
Comment by Johann Lombardi [ 28/Jan/19 ]

Thanks Nathan. Unless this is a requirement to land this patch, I would rather address those changes in follow-on patches.

Comment by Nathan Rutman [ 04/Feb/19 ]

I would rather address those changes in follow-on patches.

I get the desire to both keep it simple and minimize churn, but the (potential) price to pay is future code complexity for compat checking. Since this is an on-disk structure, we will bear that burden into the eternal future. It's very cheap to do this now (literally, just add the fields - don't even need to bother with swapping them today), very expensive to do it later. Are there concrete plans to do something with these new fields? No. But it seems like it could have value in letting Lustre make some decisions about where/when/how such external files are handled.
@adilger do you want to weigh in?

Comment by Andreas Dilger [ 04/Feb/19 ]

I think the addition of two fields into the data structure for forward compatibility is not a huge burden, and I agree with Nathan that this is easily done now and harder to do later. Using those fields for various purposes can be deferred to later patches when that functionality is needed.

Comment by Bruno Faccini (Inactive) [ 04/Feb/19 ]

Nathan, Andreas, this sounds reasonable, I will add those fields now.

Comment by Bruno Faccini (Inactive) [ 19/Feb/19 ]

In patch-set #10 of Gerrit Change #33755, new __u32 fields lmf_type and lmf_flags have been added to foreign LOV format.

In patch-set #8 of Gerrit Change #34087, new __u32 fields lmf_type and lmf_flags have been added to foreign LMV format.

 

Comment by Gerrit Updater [ 08/May/19 ]

Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/33755/
Subject: LU-11376 lov: new foreign LOV format
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 6a20bdcc608bc2b933774b9f34ec25395e920a54

Comment by Gerrit Updater [ 08/May/19 ]

Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/34087/
Subject: LU-11376 lmv: new foreign LMV format
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: fdad38781cccb05c4cf3f1458c2d2d7c8b2b5bec

Comment by Peter Jones [ 08/May/19 ]

Landed for 2.13

Comment by Gerrit Updater [ 13/May/19 ]

Andreas Dilger (adilger@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/34851
Subject: LU-11376 tests: skip sanity test_27K until it works
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: b00742d9ca6b29dfd7d1de737d36dee3068ba995

Generated at Sat Feb 10 02:43:20 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.