[lustre-devel] [External] : Re: Inquiry Regarding Checksum Support for Lustre Extended Attributes

[Patrick Farrell]

Andreas,

A few clarifying questions, partly for me and hopefully for Saisha as well as a non-Lustre expert.  The ldiskfs file system supported for Lustre disk targets is a modified ext4, so it inherits ext4 features for the local volume, but not all of them are supported for ldiskfs formatted volumes.  So does Lustre support use of metadata_csum (that's the relevant option, isn't it?) when formatting ldiskfs?  Is it on by default?

Inferring from your comments, I think you're saying metadata_csums are (or can be) used on an ldiskfs volume.  But since they are just a local disk feature, they contribute only minimally to resiliency in Lustre, and Lustre makes no use of them.  They can help protect against some damage to the local volume, but Lustre is unaware of them.

Do the metadata checksums extend to all ext4/ldiskfs extended attributes?  Are they done separately for individual xattrs or just for the whole inode?  The kernel wiki describes a possible implementation that credits someone named 'Andreas Dilger' ( :) ) with suggesting checksumming them under the inode checksum rather than separately, but I don't know what was actually implemented.

Regards,
Patrick
________________________________
From: lustre-devel <lustre-devel-bounces at lists.lustre.org> on behalf of Andreas Dilger via lustre-devel <lustre-devel at lists.lustre.org>
Sent: Wednesday, June 12, 2024 5:27 PM
To: Saisha Kamat <skamat1 at charlotte.edu>
Cc: lustre-devel <lustre-devel at lists.lustre.org>
Subject: [External] : Re: [lustre-devel] Inquiry Regarding Checksum Support for Lustre Extended Attributes

On Jun 12, 2024, at 12:35, Saisha Kamat via lustre-devel <lustre-devel at lists.lustre.org<mailto:lustre-devel at lists.lustre.org>> wrote:

Hello,

I hope this email finds you well.

My name is Saisha, and I am currently pursuing my Ph.D. at UNC-Charlotte, with a focus on research related to the Lustre File System. As part of my project, I am exploring the possibility of utilizing checksums to verify Lustre extended attributes.

My understanding is that the ext4 file system supports checksums for extended attributes (xattrs). However, I am interested in whether this functionality extends to Lustre as well.

Yes, the ext4 (and ZFS) xattr values have checksums.  No, the xattr checksums are neither managed or verified by Lustre, and only come into effect when they are passed on to the backing filesystem.  Conceivably, it would be possible to have a checksum (e.g. crc32c) for the xattr values in the MDS_GETXATTR and MDS_SETXATTR RPCs, if this is something you are interested to contribute.

This could probably be done by overloading one of the 32-bit fields in the mdt_body for getxattr, and one in mdt_rec_reint for setxattr, but there is also "opportunistic" xattr prefetching done in the lookup RPC, so that would need to be covered as well.

Also, the checksum would also need to be kept with the xattrs in cache and verified on access, otherwise they could become corrupted in memory after the RPC processing had completed.

Finally, there is no interface to specify or verify the xattr checksum in the syscall interface, so there can be no guarantee that the data supplied in the setxattr is correct, or remains correct after supplied to getxattr, but the window there is very small.

Cheers, Andreas

I would greatly appreciate it if you could provide some insights or direct me to relevant documentation on this matter. Any information or guidance you can offer would be invaluable to my research.

Thank you very much for your time and assistance.

Thanks and Regards,
Saisha
_______________________________________________
lustre-devel mailing list
lustre-devel at lists.lustre.org<mailto:lustre-devel at lists.lustre.org>
http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org<https://urldefense.com/v3/__http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org__;!!ACWV5N9M2RV99hQ!NxZsGb9nGU3ZLJa1pn9PclSTh2QUuTOnSdBLFvT4cYZxHl-jq2z3TrARWnu9vlkaS-diipwr7e73a1J0pgTw4Htt05quzd0a$>

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Whamcloud







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20240612/bc37f154/attachment-0001.htm>