All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.