From: Christoph Hellwig <hch@infradead.org>
To: Heinz Mauelshagen <heinzm@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Mikulas Patocka <mpatocka@redhat.com>,
Jooyung Han <jooyung@google.com>,
Alasdair Kergon <agk@redhat.com>,
Mike Snitzer <snitzer@kernel.org>,
zkabelac@redhat.com, dm-devel@lists.linux.dev,
linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] the dm-loop target
Date: Mon, 3 Mar 2025 07:13:49 -0800 [thread overview]
Message-ID: <Z8XHLdh_YT1Z7ZSC@infradead.org> (raw)
In-Reply-To: <CAM23VxprhJgOPfhxQf6QNWzHd6+-ZwbjSo-oMHCD2WDQiKntMg@mail.gmail.com>
On Mon, Mar 03, 2025 at 03:57:23PM +0100, Heinz Mauelshagen wrote:
> dm-loop avoids the file system abstraction, thus gains the resulting
> performance advantage versus the loop driver.
How?
> dm-loop obviously requires full provisioning, thus sparse files are being
> detected and error handled.
>
> Additionally, block relocation on CoW filesystems has to be prevented.
> dm-loop uses S_SWAPFILE to do so but that flag's limited to swap semantics
> and is overloaded as such.
>
> Should we avoid the flag and enforce use of non-CoW filesystems for backing
> or checks on non-CoW files (inode->i_flags)?
No, ->bmap is fundamentally flawed. No new code should be using it, and
we need to move the places still using it (most notably swap and the md
bitmap code) off it. It can't deal with any kind of changes to the file
system topology and is a risk to data corruption because if used in the
I/O path it bypasses the file system entirely.. If it wasn't we'd use it
in the loop driver.
next prev parent reply other threads:[~2025-03-03 15:13 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <7d6ae2c9-df8e-50d0-7ad6-b787cb3cfab4@redhat.com>
2025-03-03 13:59 ` [PATCH] the dm-loop target Christoph Hellwig
[not found] ` <CAM23VxprhJgOPfhxQf6QNWzHd6+-ZwbjSo-oMHCD2WDQiKntMg@mail.gmail.com>
2025-03-03 15:13 ` Christoph Hellwig [this message]
2025-03-03 15:22 ` Matthew Wilcox
2025-03-03 15:31 ` Christoph Hellwig
[not found] ` <CAM23VxprSduDDK8qvLVkUt9WWmLMPFjhqKB8X4e6gw7Wv-6R2w@mail.gmail.com>
2025-03-03 17:24 ` Christoph Hellwig
[not found] ` <CAM23Vxoxyrf9nwJd1Xe8uncAPiyK8yaNZNsugwX8p=qo1n6yVg@mail.gmail.com>
2025-03-04 13:52 ` Christoph Hellwig
2025-03-03 16:16 ` Mikulas Patocka
2025-03-03 17:24 ` Christoph Hellwig
2025-03-03 21:03 ` Mikulas Patocka
2025-03-04 2:13 ` Dave Chinner
2025-03-04 11:18 ` Mikulas Patocka
2025-03-04 13:50 ` Christoph Hellwig
2025-03-05 0:01 ` Dave Chinner
2025-03-07 15:21 ` Mikulas Patocka
2025-03-08 3:49 ` Darrick J. Wong
2025-03-08 20:45 ` Mikulas Patocka
2025-03-09 0:05 ` Ming Lei
2025-03-10 11:18 ` Mikulas Patocka
2025-03-11 1:27 ` Dave Chinner
2025-03-11 10:43 ` Ming Lei
2025-03-12 2:34 ` Dave Chinner
2025-03-12 6:24 ` Christoph Hellwig
2025-03-12 8:26 ` Ming Lei
2025-03-13 1:36 ` Ming Lei
2025-03-13 16:36 ` Mikulas Patocka
2025-03-18 4:27 ` Dave Chinner
2025-03-18 7:57 ` Christoph Hellwig
2025-03-18 9:34 ` Ming Lei
2025-03-20 7:08 ` Christoph Hellwig
2025-03-20 7:41 ` Ming Lei
2025-03-20 14:22 ` Christoph Hellwig
2025-03-20 14:36 ` Ming Lei
2025-03-25 10:15 ` Dave Chinner
2025-03-25 12:23 ` Ming Lei
2025-03-09 0:16 ` Ming Lei
2025-03-10 11:20 ` Mikulas Patocka
2025-03-04 13:49 ` Christoph Hellwig
[not found] ` <CAM23Vxr=fKy-0L1R5P-5h6A95acKT_d=CC1E+TAzAs8v6q9gHw@mail.gmail.com>
2025-03-04 16:04 ` Christoph Hellwig
[not found] ` <CAM23VxqJX46DCpCiH5qxPpDLtMVg87Ba8sx55aQ4hvt-XaHzuQ@mail.gmail.com>
2025-03-04 17:17 ` Christoph Hellwig
2025-03-12 13:26 ` Kent Overstreet
2025-03-12 14:20 ` Christoph Hellwig
2025-03-12 16:09 ` Kent Overstreet
2025-03-13 12:44 ` Christoph Hellwig
2025-03-13 16:21 ` Mikulas Patocka
2025-03-13 16:33 ` Kent Overstreet
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=Z8XHLdh_YT1Z7ZSC@infradead.org \
--to=hch@infradead.org \
--cc=agk@redhat.com \
--cc=dm-devel@lists.linux.dev \
--cc=heinzm@redhat.com \
--cc=jooyung@google.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=snitzer@kernel.org \
--cc=zkabelac@redhat.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;
as well as URLs for NNTP newsgroup(s).