Re: [Cluster-devel] Why does dlm_lock function fails when downconvert a dlm lock?
Hi David, On 2021/8/13 1:45, David Teigland wrote: On Thu, Aug 12, 2021 at 01:44:53PM +0800, Gang He wrote: In fact, I can reproduce this problem stably. I want to know if this error happen is by our expectation? since there is not any extreme pressure test. Second, how should we handle these error cases? call dlm_lock function again? maybe the function will fails again, that will lead to kernel soft-lockup after multiple re-tries. What's probably happening is that ocfs2 calls dlm_unlock(CANCEL) to cancel an in-progress dlm_lock() request. Before the cancel completes (or the original request completes), ocfs2 calls dlm_lock() again on the same resource. This dlm_lock() returns -EBUSY because the previous request has not completed, either normally or by cancellation. This is expected. These dlm_lock and dlm_unlock are invoked in the same node, or the different nodes? A couple options to try: wait for the original request to complete (normally or by cancellation) before calling dlm_lock() again, or retry dlm_lock() on -EBUSY. If I retry dlm_lock() repeatedly, I just wonder if this will lead to kernel soft lockup or waste lots of CPU. If dlm_lock() function returns -EAGAIN, how should we handle this case? retry it repeatedly? Thanks Gang Dave
Re: [Cluster-devel] [PATCH 11/30] iomap: add the new iomap_iter model
On Thu, Aug 12, 2021 at 11:20:17AM -0700, Darrick J. Wong wrote: > The history of the gluecode that enables us to walk a bunch of extent > mappings. In the beginning it was the _apply function, but now in our > spectre-weary world, you've switched it to a direct loop to reduce the > number of indirect calls in the hot path by 30-50%. > > As you correctly point out, there's no /code/ shared by the two > implementations, but Dave and I would like to preserve the continuity > from one to the next. > > > > I'll send the updated patches as replies to this series to avoid > > > spamming the list, since I also have a patchset of bugfixes to send out > > > and don't want to overwhelm everyone. > > > > Just as a clear statement: I think this dance is obsfucation and doesn't > > help in any way. But if that's what it takes.. > > I /would/ appreciate it if you'd rvb (or at least ack) patch 31 so I can > get the 5.15 iomap changes finalized next week. Pretty please? :) I think it is a really stupid idea, so certainly no rvb or ack from me. If you feel you want to do it this way go ahead, but I do not in any way approve of it.
