https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-6211 Lustre <p>When getxattr() is called to retrieve the lustre.lov or trusted.lov xattr of a regular file the returned value is synthesized from the LSM attached to that file. When the file is released that LSM will have a stripe count of 0.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre># lfs setstripe -c2 f0 # lfs getstripe f0 f0 lmm_stripe_count: 2 lmm_stripe_size: 1048576 lmm_pattern: 1 lmm_layout_gen: 0 lmm_stripe_offset: 0 obdidx objid objid group 0 3 0x3 0 1 3 0x3 0 # sys_getxattr --raw f0 lustre.lov | hexdump -C 00000000 d0 0b d1 0b 01 00 00 00 04 00 00 00 00 00 00 00 |................| 00000010 00 04 00 00 02 00 00 00 00 00 10 00 02 00 00 00 |................| 00000020 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000030 00 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 |................| 00000040 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 |................| 00000050 # sys_getxattr --raw f0 trusted.lov | hexdump -C 00000000 d0 0b d1 0b 01 00 00 00 04 00 00 00 00 00 00 00 |................| 00000010 00 04 00 00 02 00 00 00 00 00 10 00 02 00 00 00 |................| 00000020 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000030 00 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 |................| 00000040 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 |................| 00000050 # lfs hsm_archive f0 # lfs hsm_release f0 # lfs hsm_state f0 f0: (0x0000000d) released exists archived, archive_id:1 </pre> </div></div> <p>lfs getstripe returns the correct answer as it does not use the LSM but instead does a IOC_MDC_GETFILESTRIPE ioctl on the parent directory which calls ll_lov_getstripe_ea_info() and sends a MDS_GETATTR_NAME request.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre># lfs getstripe f0 f0 lmm_stripe_count: 2 lmm_stripe_size: 1048576 lmm_pattern: 80000001 lmm_layout_gen: 1 lmm_stripe_offset: 0 </pre> </div></div> <p>getxattr() returns the wrong answer as it uses that attached LSM:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>q:lustre# sys_getxattr -r f0 lustre.lov | hexdump -C 00000000 d0 0b d1 0b 01 00 00 80 04 00 00 00 00 00 00 00 |................| 00000010 00 04 00 00 02 00 00 00 00 00 10 00 00 00 00 00 |................| 00000020 q:lustre# sys_getxattr -r f0 trusted.lov | hexdump -C 00000000 d0 0b d1 0b 01 00 00 80 04 00 00 00 00 00 00 00 |................| 00000010 00 04 00 00 02 00 00 00 00 00 10 00 00 00 00 00 |................| 00000020 magic------ pattern---- oi--------------------- 00000000 d0 0b d1 0b 01 00 00 80 04 00 00 00 00 00 00 00 |................| ----------------------- size------- count gen-- 00000010 00 04 00 00 02 00 00 00 00 00 10 00 00 00 00 00 |................| </pre> </div></div> <p>When the LL_IOC_LOV_GETSTRIPE ioctl is done on a regular file we will also get a stripe count of 0 on a released file. But neither llapi nor lfs will use LL_IOC_LOV_GETSTRIPE on a regular file.</p> <p>Note that this code was modified recently as part of CLIO simplification (see <a href="https://jira.whamcloud.com/browse/LU-5823" title="Replace some obsolete obd operations with CLIO ioctl interface" class="issue-link" data-issue-key="LU-5823"><del>LU-5823</del></a> and <a href="http://review.whamcloud.com/12452" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/12452</a>) but the same defect existed before that commit.</p> LU-6211

getxattr() for {lustre,trusted}.lov on HSM released file returns stripe count 0

Bug Minor Open Unresolved WC Triage John Hammond hsm lov xattr Thu, 5 Feb 2015 16:05:51 +0000 Sun, 30 Jan 2022 10:52:15 +0000 Lustre 2.7.0 0 7 <p>I agree that this is inconsistent behaviour and should be fixed, though I couldn't say which result is more correct. Does this cause any specific problems that would warrant it being fixed more urgently, or is this just a quirk that can be fixed at some later time?</p> <p>This is an oldie but a goodie. I would say this probably should be a little more urgent, recently we suspect we've hit this behavior, resulting in problems with a site's archive solution which attempts to store the stripe data with the archive, so on restore it can be recreated with the same striping configuration.  It's not a show stopper, but definitely a problem and others are likely experiencing it though they may not realize it.</p> <p>Wouldn't it make sense for the HSM to archive the layout xattr <b>before</b> the file is released? That allows it to be re-used in restore, and also helps recovery if the file is lost/deleted. </p> <p>Yes, this does make great sense, however we're also chasing an issue were, apparently in some cases xattr read fails silently before the file is released =)</p> <p>On the flip side, something like the "<tt>lfs_migrate -A</tt>" code to auto-select the layout of the file based on the file size is pretty reasonable. PFL and such are good when you don't know the file size, but if you know the size in advance (e.g. restoring from HSM) then it is possible to make a better choice of the stripe count than when the file was first created.</p> <p>Not saying this bug shouldn't be fixed, just giving some options.</p> <p>No arguments here <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> Related LU-6212 Development Rank 1|hzx5qf: Rank (Obsolete) 17381 Severity