lustre-devel-lustre.org archive mirror
 help / color / mirror / Atom feed
* [lustre-devel] Reading extended attributes from a Lustre filesystem image.
@ 2021-05-01 22:25 Saisha Kamat via lustre-devel
  2021-05-04 20:17 ` Andreas Dilger via lustre-devel
  0 siblings, 1 reply; 2+ messages in thread
From: Saisha Kamat via lustre-devel @ 2021-05-01 22:25 UTC (permalink / raw)
  To: lustre-devel


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

Hello,


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.


Thanks and regards

- Saisha Kamat

[-- Attachment #1.2: Type: text/html, Size: 3895 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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [lustre-devel] Reading extended attributes from a Lustre filesystem image.
  2021-05-01 22:25 [lustre-devel] Reading extended attributes from a Lustre filesystem image Saisha Kamat via lustre-devel
@ 2021-05-04 20:17 ` Andreas Dilger via lustre-devel
  0 siblings, 0 replies; 2+ messages in thread
From: Andreas Dilger via lustre-devel @ 2021-05-04 20:17 UTC (permalink / raw)
  To: Saisha Kamat; +Cc: lustre-devel


[-- 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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2021-05-04 20:17 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-01 22:25 [lustre-devel] Reading extended attributes from a Lustre filesystem image Saisha Kamat via lustre-devel
2021-05-04 20:17 ` Andreas Dilger via lustre-devel

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).