Re: [lustre-devel] Reading extended attributes from a Lustre filesystem image.

[Andreas Dilger via lustre-devel <lustre-devel@lists.lustre.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2391 bytes --]

On May 1, 2021, at 16:25, Saisha Kamat via lustre-devel <lustre-devel@lists.lustre.org<mailto:lustre-devel@lists.lustre.org>> wrote:

I am a Ph.D student at UNCC and our team is working on the Lustre filesystem. I am reading extended attributes of the ldiskfs for every inode. I have used this source https://wiki.lustre.org/PFL2_High_Level_Design to interpret the layout in which the extended attributes are stored.

For the Lustre image we are using, there are 605 inodes out of which 253 have extended attributes. The count of lma is also 253, which is correct. However the only 22 inodes seem to have linkEA attributes and 2 inodes have lovEA attributes. The count for linkEA and lovEA is seems to be really small compared to the count for lma.
I am wondering if there is an updated document on the layout of extended attributes for the ldiskfs inodes.

link EA and lov EA are only added to "real" files visible in the filesystem namespace (under "ROOT/" in the MDT), while lma may also be added to internal files in order to be able to recover them if the directory structure gets corrupted.  The link EA is on both files and directories, while lov EA is typically only on regular files (though it can appear on directories as a "template" for how to create files within that directory).  In this case, it just sounds like your MDT is mostly empty, and only has a handful of files in it.  It may also be possible that the regular files are created with "mknod(S_IFREG)" or "open(O_CREAT|O_LOV_DELAY_CREATE)" which will not trigger the creation of a layout (lov EA) on the file.

You could probably just format a new test filesystem ("cd lustre/tests; sh llmount.sh" will use temporary files in /tmp for testing purposes, or as described in lustre/tests/cfg/local.sh or other config file as referenced by "$NAME" in the environment), then run your scan on the "empty" MDT image, and then create a few files in the client mountpoint to see how this is working.

Note that instead of interpreting the on-disk layout format yourself (which grows increasingly complex with newer features like PFL, FLR, DoM, etc.) you could use llapi_layout_get_by_xattr(), which can take an xattr read from disk and convert it to a common in-memory format that the llapi_layout_*() functions can process.

Cheers, Andreas
--
Andreas Dilger
Principal Lustre Architect
Whamcloud







[-- Attachment #1.2: Type: text/html, Size: 6922 bytes --]

[-- Attachment #2: Type: text/plain, Size: 165 bytes --]

_______________________________________________
lustre-devel mailing list
lustre-devel@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org