Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: dsterba@suse.cz
Cc: linux-btrfs@vger.kernel.org, Torstein Eide <torsteine@gmail.com>
Subject: Re: [PATCH] btrfs-progs: logical-resolve: fix the subvolume path resolution
Date: Wed, 19 Apr 2023 16:04:14 +0800	[thread overview]
Message-ID: <bb64fc47-af26-cc0c-0ba2-bdae5f9fe24c@suse.com> (raw)
In-Reply-To: <20230418235505.GU19619@twin.jikos.cz>



On 2023/4/19 07:55, David Sterba wrote:
> On Mon, Apr 17, 2023 at 05:48:10PM +0800, Qu Wenruo wrote:
>> [BUG]
>> There is a bug report that "btrfs inspect logical-resolve" can not even
>> handle any file inside non-top-level subvolumes:
>>
>>   # mkfs.btrfs $dev
>>   # mount $dev $mnt
>>   # btrfs subvol create $mnt/subv1
>>   # xfs_io -f -c "pwrite 0 16k" $mnt/subv1/file
>>   # sync
>>   # btrfs inspect logical-resolve 13631488 $mnt
>>   inode 257 subvol subv1 could not be accessed: not mounted
>>
>> This means the command "btrfs inspect logical-resolve" is almost useless
>> for resolving logical bytenr to files.
>>
>> [CAUSE]
>> "btrfs inspect logical-resolve" firstly resolve the logical bytenr to
>> root/ino pairs, then call btrfs_subvolid_resolve() to resolve the path
>> to the subvolume.
>>
>> Then to handle cases where the subvolume is already mounted somewhere
>> else, we call find_mount_fsroot().
>>
>> But if that target subvolume is not yet mounted, we just error out, even
>> if the @path is the top-level subvolume, and we have already know the
>> path to the subvolume.
>>
>> [FIX]
>> Instead of doing unnecessary subvolume mount point check, just require
>> the @path to be the mount point of the top-level subvolume.
> 
> This is a change in the semantics of the command, can't we make it work
> on non-toplevel subvolumes instead? Access to the mounted toplevel
> subvolume is not always provided, e.g. on openSUSE the subvolume layout
> does not mount 5 and there are likely other distros following that
> scheme.

But mounting 5 is not that hard if one is trying to locate the offending 
file.

The original semantics is almost impossible to make real usage, just 
check this mail:

https://lore.kernel.org/linux-btrfs/CAL5DHTFAUCKBmW_j737j8dzRvaBnKWa9Wo5VtvoAgW8f93oR9A@mail.gmail.com/

Doing a mount point search for the subvolume is fine, but requiring each 
subvolume to be mounted while top level subvolume is already mounted is 
not user friendly at all.

Thanks,
Qu

  reply	other threads:[~2023-04-19  8:04 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-17  9:48 [PATCH] btrfs-progs: logical-resolve: fix the subvolume path resolution Qu Wenruo
2023-04-17 21:17 ` Torstein Eide
2023-04-17 22:51   ` Qu Wenruo
2023-04-18 23:55 ` David Sterba
2023-04-19  8:04   ` Qu Wenruo [this message]
2023-04-19  8:55   ` Andrei Borzenkov
2023-04-19  9:50     ` Torstein Eide
2023-04-19  9:50     ` Qu Wenruo
2023-04-19 10:37       ` Andrei Borzenkov

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=bb64fc47-af26-cc0c-0ba2-bdae5f9fe24c@suse.com \
    --to=wqu@suse.com \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=torsteine@gmail.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