[LU-6838] update llog become too big before it is destroyed

Related — Sat, 17 Dec 2016 14:10:41 +0000

Update llog might be too big before it is destroyed

So with current llog destroy implementation.

/* returns negative on error; 0 if success; 1 if success & log destroyed */
int llog_cancel_rec(const struct lu_env *env, struct llog_handle *loghandle,
                    int index)
{
............
        if ((llh->llh_flags & LLOG_F_ZAP_WHEN_EMPTY) &&
            (llh->llh_count == 1) &&
            (loghandle->lgh_last_idx == LLOG_HDR_BITMAP_SIZE(llh) - 1)) {
                rc = llog_destroy(env, loghandle);
                if (rc < 0) {
                        /* Sigh, can not destroy the final plain llog, but
                         * the bitmap has been clearly, so the record can not
                         * be accessed anymore, let's return 0 for now, and
                         * the orphan will be handled by LFSCK. */
                        CERROR("%s: can't destroy empty llog #"DOSTID
                               "#%08x: rc = %d\n",
                               loghandle->lgh_ctxt->loc_obd->obd_name,
                               POSTID(&loghandle->lgh_id.lgl_oi),
                               loghandle->lgh_id.lgl_ogen, rc);
                        RETURN(0);
                }
                RETURN(LLOG_DEL_PLAIN);
        }      
}

So with llog chunk size = 32K, the LLOG_HDR_BITMAP_SIZE() will be It 261375, so the llog update record object will be destroyed until all of its bitmap is "FULL", the size will be about (each record will be about 3K, even more with bigger stripe_count)

261375 * 3k = 760M.

So we probably should destroy the llog object earlier, instead of waiting all of bits are being filled.

Whamcloud Community JIRA

[LU-6838] update llog become too big before it is destroyed