public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs-progs: remove loopback device resolution
Date: Thu, 16 Jan 2025 12:42:19 +0100	[thread overview]
Message-ID: <20250116114219.GC5777@twin.jikos.cz> (raw)
In-Reply-To: <6094201431aa981c6e0d149b6d528bc4b7a5af91.1737020580.git.wqu@suse.com>

On Thu, Jan 16, 2025 at 08:13:01PM +1030, Qu Wenruo wrote:
> [BUG]
> mkfs.btrfs has a built-in loopback device resolution, to avoid the same
> file being added to the same fs, using loopback device and the file
> itself.
> 
> But it has one big bug:
> 
> - It doesn't detect partition on loopback devices correctly
>   The function is_loop_device() only utilize major number to detect a
>   loopback device.
>   But partitions on loopback devices doesn't use the same major number
>   as the loopback device:
> 
>   NAME            MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
>   loop0             7:0    0    5G  0 loop
>   |-loop0p1       259:3    0  128M  0 part
>   `-loop0p2       259:4    0  4.9G  0 part
> 
>   Thus `/dev/loop0p1` will not be treated as a loopback device, thus it
>   will not even resolve the source file.
> 
>   And this can not even be fixed, as if we do extra "/dev/loop*" based
>   file lookup, `/dev/loop0p1` and `/dev/loop0p2` will resolve to the
>   same source file, and refuse to mkfs on two different partitions.
> 
> [FIX]
> The loopback file detection is the baby sitting that no one asks for.
> 
> Just as I explained, it only brings new bugs, and we will never fix all
> ways that an experienced user can come up with.
> And I didn't see any other mkfs tool doing such baby sitting.
> 
> So remove the loopback file resolution, just regular is_same_blk_file()
> is good enough.

The loop device resolution had some bugs in the past and was added for a
reason that's not mentioned in the changelogs.

The commits have some details why it's done, they also mention that
partitioned devices are resolved so it's not that there's no support for
that.

0cf3b78f404b01 ("btrfs-progs: Fix partitioned loop devices resolving")
abdb0ced0123d4 ("Btrfs-progs: fix resolving of loop devices")
09559bfe7bcd43 ("multidevice support for check_mounted")

and some fixup commits.

So before removing the code completely I'd like to see if there's a use
case that can be broken, but I don't have anything in particular.
There's only mkfs-tests/006-partitioned-loopdev that's quite simple and
does not try to do any tricks with symlinks or partitions on the
devices.

  reply	other threads:[~2025-01-16 11:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-16  9:43 [PATCH] btrfs-progs: remove loopback device resolution Qu Wenruo
2025-01-16 11:42 ` David Sterba [this message]
2025-01-16 20:52   ` Qu Wenruo
2025-01-17 14:01     ` David Sterba
2025-01-17 20:35       ` Qu Wenruo

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=20250116114219.GC5777@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wqu@suse.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