On Thu, Aug 12, 2021 at 08:49:14AM +0200, Christoph Hellwig wrote:
> On Wed, Aug 11, 2021 at 12:17:08PM -0700, Darrick J. Wong wrote:
> > > iter.c is also my preference, but in the end I don't care too much.
> >
> > Ok. My plan for this is to change this patch to add the new iter code
> > to
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?
Hi Alexander,
On 2021/8/12 4:35, Alexander Aring wrote:
Hi,
On Wed, Aug 11, 2021 at 6:41 AM Gang He wrote:
Hello List,
I am using kernel 5.13.4 (some old version kernels have the same problem).
When node A acquired a dlm (EX) lock, node B tried to get the dlm lock, node A
got a BAST
On Wed, Aug 11, 2021 at 12:18:00PM -0700, Darrick J. Wong wrote:
> + while ((ret = iomap_iter(, ops)) > 0) {
> + if (iter.iomap.type == IOMAP_MAPPED)
> + bno = iomap_sector(, iter.pos) >> blkshift;
> + /* leave iter.processed unset to abort loop */
>
On Wed, Aug 11, 2021 at 12:17:08PM -0700, Darrick J. Wong wrote:
> > iter.c is also my preference, but in the end I don't care too much.
>
> Ok. My plan for this is to change this patch to add the new iter code
> to apply.c, and change patch 24 to remove iomap_apply. I'll add a patch
> on the
