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-3991 Lustre <p>When running mkfs.lustre on a new file, mkfs.lustre can't create the file automatically, but reports error 2 "No such file or directory".</p> <p>This bug is introduced by <a href="https://jira.whamcloud.com/browse/LU-3682" title="&quot;tunefs.lustre --erase_params&quot; corrupts running MGS when run against device node symlink" class="issue-link" data-issue-key="LU-3682">LU-3682</a>. I will fix it. </p> LU-3991

mkfs.lustre failed to copy pool name

Bug Blocker Resolved Cannot Reproduce Emoly Liu Emoly Liu HB revzfs zfs Sun, 22 Sep 2013 09:26:24 +0000 Mon, 31 Jan 2022 04:43:12 +0000 Tue, 24 Sep 2013 17:03:38 +0000 Lustre 2.5.0 0 4 <p>patch is at <a href="http://review.whamcloud.com/7722" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/7722</a></p> <p>is this really an issue?</p> <p>Hmm, it will block llmount.sh and other lustre scripts if the given tmp file doesn't exist. And I'm afraid this problem will be complained in the future without a fix. At least, we should give a console error message about "No such file or directory".</p> <p>I find a real issue introduced by my patch for <a href="https://jira.whamcloud.com/browse/LU-3682" title="&quot;tunefs.lustre --erase_params&quot; corrupts running MGS when run against device node symlink" class="issue-link" data-issue-key="LU-3682">LU-3682</a>, which is blocking zfs testing.</p> <p>That patch removed the following code from mkfs_lustre.c:parse_opts(). </p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"><span class="code-comment">/* The device or pool/filesystem name */</span> strscpy(mop-&gt;mo_device, argv[optind], sizeof(mop-&gt;mo_device)); </pre> </div></div> <p>This is necessary for zfs to copy pool/filesystem name. I have already merged this fix into <a href="http://review.whamcloud.com/7722" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/7722</a> .</p> <p>I don't think that creating loopback files automatically is a good idea. In the normal use case (instead if during testing) any typo or error in the device name will result in a loopback file being created instead if returning a useful error to the user. For example, if someone accidentally runs "mkfs.lustre /dev/sfa" instead of "sda" this will result in a loopback file being created in /dev that will initially work, but will be very slow and will later fail when the root Filesystem runs pit of space.</p> <p>I would rather that testers/scripts make sure that the loopback file it created first, and allow mkfs.lustre to return an error if this us not done correctly.</p> <p>Please resubmit the patch with just the other bug fixes.</p> <p>Resubmit the patch. Please have a look.</p> <p>Should no longer exist now <a href="https://jira.whamcloud.com/browse/LU-3682" title="&quot;tunefs.lustre --erase_params&quot; corrupts running MGS when run against device node symlink" class="issue-link" data-issue-key="LU-3682">LU-3682</a> has been reverted</p> Related LU-3682 Development Rank 1|hzw3lb: Rank (Obsolete) 10669 Severity