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-631 Lustre <p>Ever since we moved from Lustre 1.6.6 to 1.8 I've seen issues with using<br/> the automounter and Lustre. I've finally got around to looking at what<br/> the issue is, but I'm not quite sure what the correct way to resolve it<br/> is. I think the issue will remain in 2.0+ but I didn't look closely at<br/> the code. The issue is that lov_connect which calls lov_connect_obd is<br/> an asynchronous connect that does not wait for all OSCs to be connected<br/> before returning. In the end lustre_fill_super can return before all<br/> OSCs have been set active so any file operations that caused the<br/> automount may return an error. Many lov functions check to make sure<br/> the lov_tgt_desc ltd_active flag is 1 or return -EIO.</p> <p>Original email thread from lustre-devel:<br/> <a href="http://groups.google.com/group/lustre-devel-list/browse_thread/thread/4796d88cadf9d0e9/248ebf6e3f9877f3?lnk=gst&amp;q=automount#248ebf6e3f9877f3" class="external-link" target="_blank" rel="nofollow noopener">http://groups.google.com/group/lustre-devel-list/browse_thread/thread/4796d88cadf9d0e9/248ebf6e3f9877f3?lnk=gst&amp;q=automount#248ebf6e3f9877f3</a></p> various LU-631

IO errors when using automounter and Lustre

Bug Minor Resolved Fixed Hongchao Zhang Jeremy Filizetti ptr Wed, 24 Aug 2011 21:07:49 +0000 Tue, 9 Jul 2013 12:58:04 +0000 Thu, 25 Apr 2013 17:14:07 +0000 Lustre 1.8.6 Lustre 2.4.0 0 5 <p>Hongchao</p> <p>Can you please look into this one?</p> <p>Thanks</p> <p>Peter</p> <p>the problem(-EIO) caused by "ls -l /lustre/xen1/tmp/testfile" is in "lov_enqueue", where "lov_prep_enqueue_set" find<br/> there is no available OSC to send glimpse request and the request set contains no lov_request, then it return -EIO,</p> <p> in "lov_prep_enqueue_set",<br/> ...<br/> if (!set-&gt;set_count)<br/> GOTO(out_set, rc = -EIO);<br/> ...</p> <p>here, we can wait these OSCs to be connected &amp; activated, but it will need long time if the OST is recovering, <br/> furthermore, there is still problem in the current code:<br/> if there are more than one stripes in a file, and one OSC is activated, the other isn't, then only one glimpse request<br/> is sent, and its A(CM)Time&amp;Size is taken into account, but the second one's is not! it's the same effect if we don't<br/> return "-EIO" in the above code snippet.</p> <p>I think the easiest way to make a satisfactory fix (to me) is to make sure that nothing is queued to the OSC before it has been set active so that we don't return -EIO from lov_prep_enqueue_set on operations that might have triggered the mount from the automounter.</p> <p>As for the bug you mention about not accounting for </p> {a,c,m} <p>time and size from all of the OSC if some of them are done should also be fixed. Maybe that should be tracked under a separate bug.</p> <p>Bobi</p> <p>Hongchao is out for a while. Could you please investigate this issue in his absence?</p> <p>Thanks</p> <p>Peter</p> <p>the patch is tracked at <a href="http://review.whamcloud.com/#change,2469" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#change,2469</a></p> <p>Landed for 2.4</p> <p>good patch to make MDT hang if someone will add OST which unreachable in config change time.<br/> new creation will call statfs to obtain information about new OST - and any new creation will blocked until ost connection finished.</p> Development Rank 1|hzvp2n: Rank (Obsolete) 7892 Severity