Message-ID: <CANQeFDA+cAyuQwHoufKggNtJnGnRFySZXd-jCqhUKBhL22UXKA@mail.gmail.com>
Date:   Mon, 27 Aug 2018 12:01:10 -0700
From:   Liu Bo <obuil.liubo@...il.com>
To:     linux-ext4@...r.kernel.org, Jan Kara <jack@...e.cz>
Subject: Journaled quota

Hi Jan,

I've run into a problem that "repquota" doesn't always show the latest
quota stats when using journaled quota of v2, "aquota.group".

Here's the steps:
1. quotacheck -cug /mnt
2. quotaon -g /mnt
3. setquota -g 0 0 2G 0 0 /mnt
4. repquota -g /mnt

# in step 4, it didn't always show 2G as the hardlimit

I straced repquota and had realized that it does call both ->sync_fs()
and sync_blockdev() and then truncates quota file's page cache to
avoid userspace programs reading stale quota stats.  However, the
changes that "setquota" writes to quota files are stored as metadata
in ext4 and the "bh" is then marked as "jbddirty".  At the ->sync_fs()
time, if the bh is modified by a later transaction while committing
ext4's journal, the journal bh "jh" makes it to disk while the "bh" is
not, and the "bh" is again queued in BJ_Metadata list and marked
"jbddirty", the point is "bh" is not marked as dirty so that
sync_blockdev() is not able to flush it to disk, then the end result
is that quota file "aquota.group" still has stale data which
"repquota" is reading and showing.

I found the above in an old 3.x kernel, but I've checked that the
logic also applied to 4.18.

I was wondering if it was a known problem or am I missing anything?

Could you please suggest?

thanks,
liubo

Powered by blists - more mailing lists