From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Byungchul Park <byungchul@sk.com>, Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: linux-kernel@vger.kernel.org, clm@fb.com, josef@toxicpanda.com,
dsterba@suse.com, linux-btrfs@vger.kernel.org,
kernel_team@skhynix.com, torvalds@linux-foundation.org,
akpm@linux-foundation.org, yeoreum.yun@arm.com,
yunseong.kim@ericsson.com, gwan-gyeong.mun@intel.com,
harry.yoo@oracle.com, ysk@kzalloc.com
Subject: Re: [RFC] DEPT report on around btrfs, unlink, and truncate
Date: Tue, 24 Jun 2025 12:37:41 +0930 [thread overview]
Message-ID: <f80c28ea-5c46-4caa-b2b9-6e76f45a7cfb@gmx.com> (raw)
In-Reply-To: <20250624014426.GC5820@system.software.com>
在 2025/6/24 11:14, Byungchul Park 写道:
[...]
>> I believe it's from btrfs_clear_buffer_dirty():
>>
>> As we have a for() loop iterating all the folios of a an extent buffer
>> (aka, metadata structure), then clear the dirty flags.
>>
>> The same applies to btrfs_mark_buffer_dirty() -> set_extent_buffer_dirty().
>
> Thanks to Yunseong, I figured out this is the case.
>
>> In that case, the folio is 100% belonging to btree inode thus metadata.
>
> Good to know.
>
> Lastly, is it still good with directly manipulating block devs or
> stacked file system using loopback devices, from the confliction of
> folios and extent_buffers?
Not an expert of the block device page cache, but since the
data/metadata split is fully handled by btrfs inside itself, even with
stack loopback devices the metadata/data IO from btrfs just becomes data
IO of the next layer.
Since we do not deadlock inside the btrfs, then it shouldn't cause
deadlock on lower layer, as the IO just become all data even if the
lower layer is another btrfs.
Thanks,
Qu
>
> If you confirm it, this issue can be closed :-) Thanks in advance.
>
> Byungchul
>
>> Thus the folio lock can not conflict with a data folio, thus there
>> should be no deadlock.
>>
>> Thanks,
>> Qu
>>
next prev parent reply other threads:[~2025-06-24 3:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-23 3:21 Byungchul Park
2025-06-23 5:50 ` Qu Wenruo
2025-06-23 8:19 ` Byungchul Park
2025-06-23 8:52 ` Qu Wenruo
2025-06-23 9:52 ` Byungchul Park
2025-06-23 9:58 ` Qu Wenruo
2025-06-24 1:44 ` Byungchul Park
2025-06-24 1:59 ` Byungchul Park
2025-06-24 3:07 ` Qu Wenruo [this message]
2025-06-23 12:22 ` Yunseong Kim
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=f80c28ea-5c46-4caa-b2b9-6e76f45a7cfb@gmx.com \
--to=quwenruo.btrfs@gmx.com \
--cc=akpm@linux-foundation.org \
--cc=byungchul@sk.com \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=gwan-gyeong.mun@intel.com \
--cc=harry.yoo@oracle.com \
--cc=josef@toxicpanda.com \
--cc=kernel_team@skhynix.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=yeoreum.yun@arm.com \
--cc=ysk@kzalloc.com \
--cc=yunseong.kim@ericsson.com \
/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
all inboxes | Powered by JetHome®