From: Jan Kara <jack@suse.cz>
To: Boyang Xue <bxue@redhat.com>
Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Lukas Czerner <lczerner@redhat.com>
Subject: Re: [bug report] disk quota exceed after multiple write/delete loops
Date: Thu, 22 Sep 2022 14:02:07 +0200 [thread overview]
Message-ID: <20220922120207.3jeasu24dmx5khlz@quack3> (raw)
In-Reply-To: <CAHLe9YZvOcbimNsaYa=jk27uUR1jgVDtXXztLEa0AVnqveOoyQ@mail.gmail.com>
Hello!
On Tue 23-08-22 12:16:46, Boyang Xue wrote:
> On the latest kernel 6.0.0-0.rc2, I find the user quota limit in an
> ext4 mount is unstable, that after several successful "write file then
> delete" loops, it will finally fail with "Disk quota exceeded". This
> bug can be reproduced on at least kernel-6.0.0-0.rc2 and
> kernel-5.14.0-*, but can't be reproduced on kernel-4.18.0 based RHEL8
> kernel.
<snip reproducer>
> Run log on kernel-6.0.0-0.rc2
> ```
> (...skip successful Run#[1-2]...)
> *** Run#3 ***
> --- Quota before writing file ---
> Disk quotas for user quota_test_user1 (uid 1003):
> Filesystem blocks quota limit grace files quota limit grace
> /dev/loop0 0 200000 300000 0 2000 3000
> --- ---
> dd: error writing '/mntpt/test_300m': Disk quota exceeded
> 299997+0 records in
> 299996+0 records out
> 307195904 bytes (307 MB, 293 MiB) copied, 1.44836 s, 212 MB/s
So this shows that we have failed allocating the last filesystem block. I
suspect this happens because the file gets allocted from several free space
extens and so one extra indirect tree block needs to be allocated (or
something like that). To verify that you can check the created file with
"filefrag -v".
Anyway I don't think it is quite correct to assume the filesystem can fit
300000 data blocks within 300000 block quota because the metadata overhead
gets accounted into quota as well and the user has no direct control over
that. So you should probably give filesystem some slack space in your
tests for metadata overhead.
> --- Quota after writing file ---
> Disk quotas for user quota_test_user1 (uid 1003):
> Filesystem blocks quota limit grace files quota limit grace
> /dev/loop0 300000* 200000 300000 7days 1 2000 3000
> --- ---
> --- Quota after deleting file ---
> Disk quotas for user quota_test_user1 (uid 1003):
> Filesystem blocks quota limit grace files quota limit grace
> /dev/loop0 0 200000 300000 0 2000 3000
> --- ---
> ```
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2022-09-22 12:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-23 4:16 [bug report] disk quota exceed after multiple write/delete loops Boyang Xue
2022-09-22 12:02 ` Jan Kara [this message]
2022-09-23 7:37 ` Boyang Xue
2022-09-23 10:28 ` Jan Kara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220922120207.3jeasu24dmx5khlz@quack3 \
--to=jack@suse.cz \
--cc=bxue@redhat.com \
--cc=lczerner@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).