Whamcloud Community JIRA

Whamcloud Community JIRA https://jira.whamcloud.com This file is an XML representation of an issue en-us

9.4.14

940014

05-12-2023

[LU-2190] failure on conf-sanity.sh test_49: Different LDLM_TIMEOUT:6 20 20 https://jira.whamcloud.com/browse/LU-2190 Lustre <p>This issue was created by maloo for Li Wei <liwei@whamcloud.com></p> <p>This issue relates to the following test suite run: <a href="https://maloo.whamcloud.com/test_sets/6f4fd31a-1735-11e2-afe1-52540035b04c" class="external-link" target="_blank" rel="nofollow noopener">https://maloo.whamcloud.com/test_sets/6f4fd31a-1735-11e2-afe1-52540035b04c</a>.</p> <p>The sub-test test_49 failed with the following error:</p> <blockquote> <p>Different LDLM_TIMEOUT:6 20 20</p></blockquote> <p>Info required for matching: conf-sanity 49</p> LU-2190

failure on conf-sanity.sh test_49: Different LDLM_TIMEOUT:6 20 20

Bug Minor Resolved Fixed Lai Siyao Maloo sequoia zfs Tue, 16 Oct 2012 00:49:58 +0000 Tue, 7 Jun 2016 03:05:16 +0000 Wed, 13 Mar 2013 05:07:53 +0000 Lustre 2.4.0 Lustre 2.4.0 0 11 <p><a href="https://maloo.whamcloud.com/test_sets/18e3b25c-2f96-11e2-bd52-52540035b04c" class="external-link" target="_blank" rel="nofollow noopener">https://maloo.whamcloud.com/test_sets/18e3b25c-2f96-11e2-bd52-52540035b04c</a></p> <p>Lai will work on this one</p> <p>Hi Alex, zfs_write_ldd() doesn't write parameters except "PARAM_ID_UPCALL", is this on purpose, or they are missing?</p> <p>If it's on purpose, then current test framework needs to set these parameters (eg. timeout, at_min...) explictely via `lctl conf_param ...`, this will be a lot of changes. Besides customer may find their previous script not working properly.</p> <p>Any suggestion for this?</p> <p>no, you're right that zfs_write_ldd() should be putting all the parameters into some variable. I'd suggest to introduce another zfs property to store all the parameters, but let's clarify with Brian he is OK with that.</p> <p>Brian, would you be OK if we store all the parameters an user specify into a single ZFS property. parse_ldd() prefix all the parameters found in mountdata and obd_mount.c recognizes this prefix properly. I guess one possible issue is compatibility with the existing setups, but I hope we can work this around easily.</p> <p>Ideally, these properties would be added to the normal conf_param log, so that we didn't have to have two different places to look for them, but I agree that this may make things more complex for format-time config parameters.</p> <p>I think it is fine to store the mount config parameters as a ZFS property. Please use a name like "org.lustre.ldd" or something, which is standard for this type of property.</p> <p>I made a patch at <a href="http://review.whamcloud.com/#change,4732" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#change,4732</a>, but I'm not sure it fits your requirement, please check it.</p> <p>Alex, no we want to keep them all as separate ZFS user properties. ZFS supports are arbitrary number of user properties of the form lustre:<key>=<value> which are easily accessible in both kernel space and user space. From the user perspective we've already found this to be far more convenient than how ldiskfs stores this data. Why would you want to collapse them to a single entry?</p> <p>Brian, because then you need to know literally all possible parameters. and one adding a new parameter would need to modify mount_utils_zfs.c as well.<br/> I tend to think this is a potential source of different issues in the future.</p> <p>Patch is landed on master.</p> <p>Maybe we weren't clear enough. We do NOT want this! This change was not at all backwards compatible, and has now broken Lustre on our ZFS systems. Please revert!</p> <p>I pushed a patch to revert that commit here: <a href="http://review.whamcloud.com/5144" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/5144</a></p> <p>Chris or Prakash, can you please comment on which specific parameters you are setting with these dataset properties before the patch landed that broke your mouting?</p> <p>Are you looking to be able to store arbitrary configuration parameters on the ZFS dataset as properties, or only a specific limited number of parameters that are needed during mount that cannot be fetched from the MGS config?</p> <p>Andreas, I think for ZFS OSDs we need to absolutely store all the Lustre parameters of interest to an administrator this way. Certainly everything the administrator might need to modify, and potentially make the rest visible as read-only properties. It makes it far easier to 1) know what options are available, 2) verify what they are set too, and 3) change a particular option. As a nice bonus we can even cleanly register callbacks so Lustre gets notified when one of them is changed so they may be modified online. This is an ideal interface for Lustre to use. If it needs to be extended in some way for Lustre we should look in to that. Frankly, as it was done for ldiskfs was a constant pain anytime something needed to change so I'd like to avoid that entirely with ZFS if we can.</p> <p>In fact, doing it this way already has saved us a lot of trouble in one instance where we needed to clear a single bit in the ldd flags on all the servers due to a registration bug. We were able to trivially clear the single bit we needed and verify that change across all the servers. It was soooooooo nice.</p> <p>Brian,<br/> storing the individual fields from "lustre_disk_data" (e.g. ldd_flags) is not in question here. The original issue is that while the lustre_disk_data struct an "ldd_params" field for storing arbitrary configuration strings, it was split into separate fields for only ZFS. This patch restored it to the original behaviour of just containing a string of parameters that didn't need to be handled individually and explicitly in userspace, and keeps the handling uniform between ZFS and ldiskfs. Without this, there were a number of parameters (e.g. "timeout", "network", etc) that were not explicitly handled, and this would add an ongoing extra maintenance effort.</p> <p>I have no objection to restore the 4 parameters that were disabled by the <a href="http://review.whamcloud.com/4732" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/4732</a> patch:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>#define LDD_MGSNODE_PROP "lustre:mgsnode" #define LDD_FAILNODE_PROP "lustre:failnode" #define LDD_FAILMODE_PROP "lustre:failmode" #define LDD_IDENTITY_UPCALL_PROP "lustre:identity_upcall" </pre> </div></div> <p>since they are the only ones that could have been broken by this patch (though strictly only the first three are needed, "identity_upcall" could be set from the MGS for all MDTs).</p> <p>"ldd_params" is intended for a limited number of parameters (e.g. mgsnode, failnode, etc) that need to be set on a per-target basis when the filesystem is mounted and do not have /proc/fs/lustre equivalents. The remaining global parameters can be fetched from the MGS config log for all OSTs, or they would have to be updated manually for every MDT or OST in the filesystem, and applied for every new target that is added.</p> <p>I now see that the "network" option is not explicitly supported by the "lustre:*" parsing, which would need to be added in addition to explicit "timeout" and potentially other tunables.</p> <p>Separately, if there is a desire for setting arbitrary parameters in lprocfs for a particular ZFS target (i.e. anything in /proc/fs/lustre/</p> {type} <p>/</p> {name} <p>/</p> {parameter}) a generic mechanism could be created to find and parse ZFS properties of the form "lustre:param:{parameter} <p>" for that target.</p> <p>I agree that the Lustre configuration code could be improved, and there is a desire to do this for Chroma as well, but I don't think this bug is the right place to do that design.</p> <p>Note that for ldiskfs, unlike ZFS, there is no space for arbitrary parameter storage beyond the "ldd_params" field, so it wouldn't be possible to add/remove individual parameters for ldiskfs without essentially writing helpers to extract them and concatenate them again in mount_utils_ldiskfs.c and in the kernel, and it still wouldn't be shared between kernel & userspace like the ZFS dataset properties are today.</p> <p>> storing the individual fields from "lustre_disk_data" (e.g. ldd_flags) is not in question here.</p> <p>Ahh good, that was part of my misunderstanding. That's my fault for not actually looking at the patch. Then to be perfectly clear the following lustre_disk_data entries will be left as properties.</p> <p>```<br/> /* Persistent mount data is stored in these user attributes */<br/> #define LDD_VERSION_PROP "lustre:version" /* ldd->ldd_config_ver */<br/> #define LDD_FLAGS_PROP "lustre:flags" /* ldd->ldd_flags */<br/> #define LDD_INDEX_PROP "lustre:index" /* ldd->ldd_svindex /*<br/> #define LDD_FSNAME_PROP "lustre:fsname" /* ldd->ldd_fsname */<br/> #define LDD_SVNAME_PROP "lustre:svname" /* ldd->ldd_svname */<br/> #define LDD_UUID_PROP "lustre:uuid" /* ldd->ldd_uuid */<br/> #define LDD_USERDATA_PROP "lustre:userdata" /* ldd->ldd_userdata */<br/> #define LDD_MOUNTOPTS_PROP "lustre:mountopts" /* ldd->ldd_mount_ops */<br/> ```</p> <p>> "ldd_params" is intended for a limited number of parameters (e.g. mgsnode, failnode, etc) that need to be set on a per-target basis when the filesystem is mounted...</p> <p>Correct me if I'm wrong, but the only reason to make this distinction in the first place (which is subtle and totally non-obvious to an end user) is so these options can be passed as a string to mount(2). Exactly how the lustre_disk_data gets stored on disk for a particular osd should be handled by that osd. We wouldn't want the limitations of any one OSD to dictate to the others how this data must be stored. That's why the wrapper osd_write_ldd() and osd_read_ldd() functions were added in the first place.</p> <p>It sounds to me like the problem here isn't that they are stored on disk differently, it's that several were omitted in the initial implementation. Let me propose a new patch (today/tomorrow) which instead of collapsing these individual ZFS properties in to ldd_params adds all the missing PARAM_*s in a generic fashion. The LDD_MSGNODE_PROP, LDD_FAILNODE_PROP, LDD_FAILMODE_PROP, and LDD_INDENTITY_UPCALL_PROP will be removed and the ZFS property names for params can be dynamically generated as 'lustre:<param key>'. This way if you add a new PARAM_XYZ you won't need to update the zfs_read_ldd() or zfs_write_ldd() functions. That should address your maintenance concerns. For LDD_FAILNODE_PROP->PARAM_FAILNODE and LDD_FAILMODE_PROP->PARAM_FAILMODE where the names currently differ we can rename the property on our existing file systems to avoid the need for compatibility code. Presumably there aren't other sites running ZFS just yet (are there?).</p> <p>On a related but separate note, it would be awfully to nice to someday pass a versioned 'struct lustre_disk_data' as the mount data instead of this string. This would effectively eliminate a lot of the current parsing headaches. Or better yet, the lustre_disk_data could be read from disk in the context of mount(2). But that's of course a much more ambitious bit of development work.</p> <p>Please see: <a href="http://review.whamcloud.com/5220" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/5220</a></p> <p>Patch landed to master. Please reopen or let me know if I need to reopen if more work needs to be done.</p> <p>Isn't <a href="http://review.whamcloud.com/#change,5671" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#change,5671</a> needed also?</p> <p>Yes, <a href="http://review.whamcloud.com/5671" class="external-link" target="_blank" rel="nofollow noopener">5671</a> is the one that we need at LLNL.</p> <p>Oh, sorry, that looks like code cleanup in 5671, not critical.</p> <p>ok then let's reopen but lower the priority to track the code cleanup patch landing</p> <p>all needed patches landed.</p> <p>Now that <a href="http://review.whamcloud.com/#change,5671" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#change,5671</a> has landed, can this ticket be closed?</p> <p>From my point of view it can be closed. Thanks.</p> <p>Hit it again on master:<br/> <a href="https://testing.hpdd.intel.com/test_sets/ce06c2b0-2b04-11e6-a0ce-5254006e85c2" class="external-link" target="_blank" rel="nofollow noopener">https://testing.hpdd.intel.com/test_sets/ce06c2b0-2b04-11e6-a0ce-5254006e85c2</a></p> <p>If a bug hasn't been hit in 3+ years, but the same test fails again it deserves to have a new bug filed.</p> <p>New ticket for this failure:<br/> <a href="https://jira.hpdd.intel.com/browse/LU-8243" class="external-link" target="_blank" rel="nofollow noopener">https://jira.hpdd.intel.com/browse/LU-8243</a></p> Development Rank 1|hzvahb: Rank (Obsolete) 5233 Severity