• Bob Peterson's avatar
    gfs2: Issue revokes more intelligently · 5e4c7632
    Bob Peterson authored
    Before this patch, function gfs2_write_revokes would call
    gfs2_ail1_empty, then traverse the sd_ail1_list looking for
    transactions that had bds which were no longer queued to a glock.
    And if it found some, it would try to issue revokes for them, up to
    a predetermined maximum. There were two problems with how it did
    this. First was the fact that gfs2_ail1_empty moves transactions
    which have nothing remaining on the ail1 list from the sd_ail1_list
    to the sd_ail2_list, thus making its traversal of sd_ail1_list
    miss them completely, and therefore, never issue revokes for them.
    Second was the fact that there were three traversals (or partial
    traversals) of the sd_ail1_list, each of which took and then
    released the sd_ail_lock lock: First inside gfs2_ail1_empty,
    second to determine if there are any revokes to be issued, and
    third to actually issue them. All this taking and releasing of the
    sd_ail_lock meant other processes could modify the lists and the
    conditions in which we're working.
    
    This patch simplies the whole process by adding a new parameter
    to function gfs2_ail1_empty, max_revokes. For normal calls, this
    is passed in as 0, meaning we don't want to issue any revokes.
    For function gfs2_write_revokes, we pass in the maximum number
    of revokes we can, thus allowing gfs2_ail1_empty to add the
    revokes where needed. This simplies the code, allows for a single
    holding of the sd_ail_lock, and allows gfs2_ail1_empty to add
    revokes for all the necessary bd items without missing any.
    Signed-off-by: default avatarBob Peterson <rpeterso@redhat.com>
    Reviewed-by: default avatarAndreas Gruenbacher <agruenba@redhat.com>
    5e4c7632
log.c 29.4 KB