Linux XFS filesystem development
 help / color / mirror / Atom feed
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

  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