Received-SPF: pass (google.com: domain of linux-ext4+bounces-18-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
From: bugzilla-daemon@kernel.org
To: linux-ext4@vger.kernel.org
Subject: [Bug 217965] ext4(?) regression since 6.5.0 on sata hdd
Date: Thu, 16 Nov 2023 03:15:33 +0000
Message-ID: <bug-217965-13602-acQutmnfg8@https.bugzilla.kernel.org/>
In-Reply-To: <bug-217965-13602@https.bugzilla.kernel.org/>
References: <bug-217965-13602@https.bugzilla.kernel.org/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Auto-Submitted: auto-generated
Precedence: bulk
MIME-Version: 1.0

https://bugzilla.kernel.org/show_bug.cgi?id=3D217965

--- Comment #27 from Ojaswin Mujoo (ojaswin.mujoo@ibm.com) ---
Hey Eyal,

So the way most file systems handle their writes is:

1. Data is written to memory buffers aka pagecache=20

2. When writeback/flush kicks in, FS tries to group adjacent data together =
and
allocates disk blocks for it=20

3. Finally, send the data to lower levels like blocks layer -> raid -> scsi=
 etc
for the actual write.

The practice of delaying the actual allocation till writeback/flush is know=
n as
delayed allocation or delalloc in ext4 and is on by default (other FSes mig=
ht
have different names).  This is why the ext4 allocation related functions
(ext4_mb_regular_allocator etc) show up in your perf report of the flusher
thread.

With delaloc, we are sending bigger requests to the ext4 allocator since we=
 try
to group together buffers. With nodelalloc we disable this so fs block
allocation happens when we are dirtying the buffers (in step 1 above) and we
only allocate as much as that write asked for thus sending smaller requests=
 at
a time. Since with delalloc we see that your flusher seemed to be taking a =
lot
of time in ext4 allocation routines, I wanted to check if a change in
allocation pattern via nodelalloc could help us narrow down the issue.

Using:

$ sudo mount -o remount,nodelalloc /data1

should be safe and preserve your other mount options so you can give it a t=
ry.

Lastly, thanks for the perf report however I'm sorry I forgot to mention th=
at i
was actually looking for the call graph, which could be collected as follow=
s:

$ sudo perf record -p 1234 -g sleep 60

Can you please share the report of the above command.

Thanks!=20=20
Ojaswin

--=20
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.=