linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Filipe Manana <fdmanana@gmail.com>
To: Anand Jain <anand.jain@oracle.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH v2] btrfs: fix warn_on for send from readonly mount
Date: Mon, 2 Dec 2019 15:42:21 +0000	[thread overview]
Message-ID: <CAL3q7H6n3Cwi6WobN1FY5ZZyhwGFLGvXbV5-Sp2q4=xGn6ZBLw@mail.gmail.com> (raw)
In-Reply-To: <1575296676-16470-1-git-send-email-anand.jain@oracle.com>

On Mon, Dec 2, 2019 at 2:26 PM Anand Jain <anand.jain@oracle.com> wrote:
>
> We log warning if root::orphan_cleanup_state is not set to
> ORPHAN_CLEANUP_DONE in btrfs_ioctl_send(). However if the filesystem is
> mounted as readonly we skip the orphan items cleanup during the lookup
> and root::orphan_cleanup_state remains at the init state 0 instead of
> ORPHAN_CLEANUP_DONE (2).
>
> WARNING: CPU: 0 PID: 2616 at /Volumes/ws/btrfs-devel/fs/btrfs/send.c:7090 btrfs_ioctl_send+0xb2f/0x18c0 [btrfs]
> ::
> RIP: 0010:btrfs_ioctl_send+0xb2f/0x18c0 [btrfs]
> ::
> Call Trace:
> ::
> _btrfs_ioctl_send+0x7b/0x110 [btrfs]
> btrfs_ioctl+0x150a/0x2b00 [btrfs]
> ::
> do_vfs_ioctl+0xa9/0x620
> ? __fget+0xac/0xe0
> ksys_ioctl+0x60/0x90
> __x64_sys_ioctl+0x16/0x20
> do_syscall_64+0x49/0x130
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> Reproducer:
>   mkfs.btrfs -fq /dev/sdb && mount /dev/sdb /btrfs
>   btrfs subvolume create /btrfs/sv1
>   btrfs subvolume snapshot -r /btrfs/sv1 /btrfs/ss1
>   umount /btrfs && mount -o ro /dev/sdb /btrfs
>   btrfs send /btrfs/ss1 -f /tmp/f
>
> Fix this by removing the warn_on completely because:
>
> 1) Having orphan items means we could have files to delete (link count
> of 0) and dealing with such cases could make send fail for several
> reasons.
>    If this happens, it's not longer a problem since the following
> commit:
>    46b2f4590aab71d31088a265c86026b1e96c9de4
>    Btrfs: fix send failure when root has deleted files still open

The convention for mentioning commits is
first_12_or_slighly_more_hash_characters ("subject").
scripts/checkpatch.pl warns about it, and given this has been around
for years, you should already be familiar with it.

>
> 2) Orphan items used to indicate previously unfinished truncations, in
> which case it would lead to send creating corrupt files at the
> destination (i_size incorrect and the file filled with zeroes between
> real i_size and stale i_size).
>    We no longer need to create orphans for truncations since commit:
>    f7e9e8fc792fe2f823ff7d64d23f4363b3f2203a
>    Btrfs: stop creating orphan items for truncate

And I didn't expect you to literally copy-paste what I wrote before.
For a changelog we want something better written, organized and more
detailed then an informal e-mail reply, like this:

"
The warning exists because having orphanized inodes could confuse send
and cause it to fail or produce incorrect streams.
The two cases that would cause problems were:

1) Inodes that were unlinked - these are orphanized and remain with a
link count of 0, having no references (names).
   These caused send operations to fail because it expected to always
find at least one path for an inode.
   This is no longe a problem since send is now able to deal with such
inodes since
   commit 46b2f4590aab ("Btrfs: fix send failure when root has deleted
files still open") and treats them as having
   been completely removed (the state after a orphan cleanup is performed).

2) Inodes that were in the process of being truncated. These resulted
in send not knowing about the truncation
    and potentially issue write operations full of zeroes for the
range from the new file size to the old file size.
    This is no longer a problem because we no longer create orphan
items for truncations since
    commit  f7e9e8fc792f ("Btrfs: stop creating orphan items for truncate").

In other words the warning was there to provide a clue in case
something went wrong. Instead of being a warning
against the root's "->orphan_cleanup_state" value, it could have been
more accurate by checking if there were actually
any orphan items, and then issue a warning only if any exists, but
that would be more expensive to check.
Since orphanized inodes no longer cause problems for send, just remove
the warning.
"

>
> Reported-by: Christoph Anton Mitterer <calestyo@scientia.net>
> Suggested-by: Filipe Manana <fdmanana@gmail.com>

Also s/@gmail.com/@suse.com/ (preferable).

Thanks.

> Signed-off-by: Anand Jain <anand.jain@oracle.com>
> ---
> v2:
>  Remove WARN_ON() completely.
>
>  fs/btrfs/send.c | 6 ------
>  1 file changed, 6 deletions(-)
>
> diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
> index ae2db5eb1549..091e5bc8c7ea 100644
> --- a/fs/btrfs/send.c
> +++ b/fs/btrfs/send.c
> @@ -7084,12 +7084,6 @@ long btrfs_ioctl_send(struct file *mnt_file, struct btrfs_ioctl_send_args *arg)
>         spin_unlock(&send_root->root_item_lock);
>
>         /*
> -        * This is done when we lookup the root, it should already be complete
> -        * by the time we get here.
> -        */
> -       WARN_ON(send_root->orphan_cleanup_state != ORPHAN_CLEANUP_DONE);
> -
> -       /*
>          * Userspace tools do the checks and warn the user if it's
>          * not RO.
>          */
> --
> 1.8.3.1
>


-- 
Filipe David Manana,

“Whether you think you can, or you think you can't — you're right.”

  reply	other threads:[~2019-12-02 15:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-02  9:44 [PATCH] btrfs: fix warn_on for send from readonly mount Anand Jain
2019-12-02  9:48 ` Nikolay Borisov
2019-12-02 11:23 ` Filipe Manana
2019-12-02 14:07   ` Anand Jain
2019-12-02 14:24 ` [PATCH v2] " Anand Jain
2019-12-02 15:42   ` Filipe Manana [this message]
2019-12-02 23:59     ` Anand Jain
2019-12-03 11:45       ` Filipe Manana
2019-12-05 11:39 ` [PATCH v3] " Anand Jain
2019-12-05 11:43   ` Filipe Manana
2019-12-05 11:45     ` Anand Jain
2019-12-10 16:51       ` David Sterba

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='CAL3q7H6n3Cwi6WobN1FY5ZZyhwGFLGvXbV5-Sp2q4=xGn6ZBLw@mail.gmail.com' \
    --to=fdmanana@gmail.com \
    --cc=anand.jain@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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).