From: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
To: Dave Chinner <dgc@kernel.org>
Cc: "linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
"Darrick J. Wong" <djwong@kernel.org>,
John Garry <john.garry@linux.dev>
Subject: Re: [bug report] fstests generic/774 hang again
Date: Thu, 17 Sep 2026 15:52:01 +0900 [thread overview]
Message-ID: <aquJIL3Ztk3KBdHV@shinmob> (raw)
In-Reply-To: <aqsN4GOXthkF8rOI@dread>
On Sep 17, 2026 / 07:45, Dave Chinner wrote:
[...]
>
> IOWs, smells of the journal being run out of reservation space, and
> no new space being able to be freed because all the dirty inodes
> in the journal that need to be written back to free up space are
> locked waiting for journal space to come free....
>
> How big is the journal in the filesystem being tested? If you
> increase the size of the journal, does it go away? Can you get a
> dump of the transaction reservation sizes for the filesystem in
> question (the xfs_db logres command can do this, IIRC) and then run
> the math on the reservations held from the dump of all the blocked
> tasks holding locks to see if this matches the size of the journal
> in the fs?
Dave, thanks for the comments. I recreated the hang, and gathered relevant
numbers [3]. Here, /dev/sdh is the SCRATCH_DEV. My interpretations are
as follows (If I misunderstand anything correction will be appreciated):
- The log section size is 4096 * 16384 = 64MiB.
- The type 26 logres has 327552 size and logcount 5, then each blocking task
consumes about 1.6MiB
- My test node has 24 nproc, and the test case creases 2 * nproc * LOAD_FACTOR
threads. LOAD_FACTOR is 1, then it creates 48 fio threads.
Assuming all fio threads are blocked, and each thread consumes 16MiB in the
log section, 1.6MiB * 48 = 76.8Mib will be consumed. This is beyond the log
section size 64MiB. The sysfs attributes reserve_grant_head_bytes has the
number close to 64MiB, and I guess it implies the log section is almost full.
Based on these, Dave's guess look correct.
As suggested, now I'm trying to increase the journal/log section size.
I added the mkfs options below:
MKFS_OPTIONS="-l size=128m"
With this, I repeated the test case 30 times, and did not observe the hang.
It looks like the log section size increase avoids the hang. I will keep it on
running to see if the hang is observed after 100 times run.
[3]
$ sudo xfs_info /dev/sdh
meta-data=/dev/sdh isize=512 agcount=4, agsize=524288 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=1, rmapbt=1
= reflink=1 bigtime=1 inobtcount=1 nrext64=1
= exchange=1 metadir=0
data = bsize=4096 blocks=2097152, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=1
log =internal log bsize=4096 blocks=16384, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
= rgcount=0 rgsize=0 extents
= zoned=0 start=0 reserved=0
$ sudo xfs_db -c logres -r /dev/sdh
type 0 logres 193528 logcount 5 flags 0x4
type 1 logres 327552 logcount 5 flags 0x4
type 2 logres 428160 logcount 5 flags 0x4
type 3 logres 247204 logcount 5 flags 0x4
type 4 logres 230820 logcount 5 flags 0x4
type 5 logres 312612 logcount 6 flags 0x4
type 6 logres 311460 logcount 5 flags 0x4
type 7 logres 285696 logcount 2 flags 0x4
type 8 logres 311460 logcount 6 flags 0x4
type 9 logres 303992 logcount 2 flags 0x4
type 10 logres 2168 logcount 0 flags 0x0
type 11 logres 82176 logcount 2 flags 0x4
type 12 logres 116856 logcount 2 flags 0x4
type 13 logres 760 logcount 0 flags 0x0
type 14 logres 326784 logcount 1 flags 0x4
type 15 logres 23288 logcount 3 flags 0x4
type 16 logres 21760 logcount 0 flags 0x0
type 17 logres 164480 logcount 3 flags 0x4
type 18 logres 640 logcount 0 flags 0x0
type 19 logres 111864 logcount 2 flags 0x4
type 20 logres 4224 logcount 0 flags 0x0
type 21 logres 6512 logcount 0 flags 0x0
type 22 logres 232 logcount 1 flags 0x0
type 23 logres 197751 logcount 5 flags 0x4
type 24 logres 640 logcount 1 flags 0x0
type 25 logres 760 logcount 0 flags 0x0
type 26 logres 327552 logcount 5 flags 0x4
minlogsize logres 428160 logcount 5
$ grep . /sys/fs/xfs/sdh/log/*
/sys/fs/xfs/sdh/log/log_head_lsn:1:103190
/sys/fs/xfs/sdh/log/log_tail_lsn:1:101012
/sys/fs/xfs/sdh/log/reserve_grant_head_bytes:66053588
/sys/fs/xfs/sdh/log/write_grant_head_bytes:65718696
next prev parent reply other threads:[~2026-09-17 6:52 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-15 9:34 [bug report] fstests generic/774 hang again Shin'ichiro Kawasaki
2026-09-15 10:00 ` John Garry
2026-09-15 11:48 ` Shin'ichiro Kawasaki
2026-09-15 14:48 ` John Garry
2026-09-15 14:50 ` Darrick J. Wong
2026-09-15 15:41 ` John Garry
2026-09-16 10:23 ` John Garry
2026-09-16 22:23 ` Dave Chinner
2026-09-17 8:28 ` John Garry
2026-09-17 21:20 ` Dave Chinner
2026-09-17 6:30 ` Shin'ichiro Kawasaki
2026-09-16 2:53 ` Shin'ichiro Kawasaki
2026-09-16 21:45 ` Dave Chinner
2026-09-17 6:52 ` Shin'ichiro Kawasaki [this message]
2026-09-17 10:45 ` Shin'ichiro Kawasaki
2026-09-17 21:24 ` Dave Chinner
2026-09-19 11:53 ` Shin'ichiro Kawasaki
2026-09-21 22:05 ` Dave Chinner
2026-09-25 1:32 ` Shin'ichiro Kawasaki
2026-09-27 21:30 ` Dave Chinner
2026-09-28 2:45 ` Darrick J. Wong
2026-09-22 0:28 ` Darrick J. Wong
2026-09-25 1:38 ` Shin'ichiro Kawasaki
2026-09-25 23:03 ` Darrick J. Wong
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=aquJIL3Ztk3KBdHV@shinmob \
--to=shinichiro.kawasaki@wdc.com \
--cc=dgc@kernel.org \
--cc=djwong@kernel.org \
--cc=john.garry@linux.dev \
--cc=linux-xfs@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