Hi Ross,
- Original Message -
> > I think the problem may actually be a regression with patch 588bff95c94ef.
>
> I still hit the assertion with this patch. gfs2_log_write_header() is
> unconditionally called and it calls gfs2_log_bmap() which changes
> sd_log_flush_head in the success pat
On 3/25/19 3:29 PM, Bob Peterson wrote:
- Original Message -
I think I've found the cause of the assertion I was hitting. Recovery
sets sd_log_flush_head but does not take locks which means a concurrent
call to gfs2_log_flush() can result in sd_log_head being set to
sd_log_flush_head. A
- Original Message -
> I think I've found the cause of the assertion I was hitting. Recovery
> sets sd_log_flush_head but does not take locks which means a concurrent
> call to gfs2_log_flush() can result in sd_log_head being set to
> sd_log_flush_head. A later call to gfs2_log_flush() will
On 3/19/19 6:48 PM, Bob Peterson wrote:
- Original Message -
Hi,
Occasionally during testing, we see the following assertion failure in
log_pull_tail():
[ 1104.061245] gfs2: fsid=xapi-clusterd:2d2cc24c-c48a-ca.0: fatal:
assertion "atomic_read(&sdp->sd_log_blks_free) <=
sdp->sd_jdesc->j
- Original Message -
> Hi,
>
> Occasionally during testing, we see the following assertion failure in
> log_pull_tail():
>
> [ 1104.061245] gfs2: fsid=xapi-clusterd:2d2cc24c-c48a-ca.0: fatal:
> assertion "atomic_read(&sdp->sd_log_blks_free) <=
> sdp->sd_jdesc->jd_blocks" failed
> [ 1104.0
Hi,
Occasionally during testing, we see the following assertion failure in
log_pull_tail():
[ 1104.061245] gfs2: fsid=xapi-clusterd:2d2cc24c-c48a-ca.0: fatal:
assertion "atomic_read(&sdp->sd_log_blks_free) <=
sdp->sd_jdesc->jd_blocks" failed
[ 1104.061245]function = log_pull_tail, file
