All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Josef Bacik <josef@toxicpanda.com>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-nfs@vger.kernel.org, Chuck Lever <chuck.lever@oracle.com>
Subject: Re: nfs generic/373 failure after "fs: allow cross-vfsmount reflink/dedupe"
Date: Wed, 2 Mar 2022 19:50:01 -0500	[thread overview]
Message-ID: <20220303005001.GB21944@fieldses.org> (raw)
In-Reply-To: <YiAL7uNA3ZiaBCE6@localhost.localdomain>

On Wed, Mar 02, 2022 at 07:29:34PM -0500, Josef Bacik wrote:
> On Wed, Mar 02, 2022 at 07:07:35PM -0500, J. Bruce Fields wrote:
> > Sorry, took me a minute to understand, myself:
> > 
> > It's actually only the client behavior that changed.  Previously the
> > client would reject an attempt to clone across filesystems, so the
> > server never saw such a request.  After this patch, the client will go
> > ahead and send the CLONE.  (Which, come to think of it, is probably the
> > right thing for the client to do.)
> > 
> > So the server's probably always had a bug, and this just uncovered it.
> > 
> > I'd be curious what the consequences are.  And where the check should be
> > (above or below vfs_clone_file_range()?).
> > 
> 
> This is where I'm confused, this really shouldn't succeed
> 
> loff_t do_clone_file_range(struct file *file_in, loff_t pos_in,
>                            struct file *file_out, loff_t pos_out,
>                            loff_t len, unsigned int remap_flags)
> {
>         loff_t ret;
> 
>         WARN_ON_ONCE(remap_flags & REMAP_FILE_DEDUP);
> 
>         if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
>                 return -EXDEV;
> 
> 
> loff_t vfs_clone_file_range(struct file *file_in, loff_t pos_in,
>                             struct file *file_out, loff_t pos_out,
>                             loff_t len, unsigned int remap_flags)
> {
>         loff_t ret;
> 
>         file_start_write(file_out);
>         ret = do_clone_file_range(file_in, pos_in, file_out, pos_out, len,
>                                   remap_flags);
> 
> And even if we get past here, I imagine XFS would freak out because it can't
> find the extents (unless you're getting lucky and everything is lining up?).
> I'm super confused...

Bah, I see what you mean.  Maybe there's something wrong with my setup.
I'll try some more stuff and report back....

--b.

  reply	other threads:[~2022-03-03  0:50 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-01 18:42 [PATCH v3 0/6] Generic per-sb io stats Amir Goldstein
2022-03-01 18:42 ` [PATCH v3 1/6] lib/percpu_counter: add helpers for arrays of counters Amir Goldstein
2022-03-01 18:42 ` [PATCH v3 2/6] fs: add optional iostats counters to struct super_block Amir Goldstein
2022-03-01 18:42 ` [PATCH v3 3/6] fs: collect per-sb io stats Amir Goldstein
2022-03-01 18:42 ` [PATCH v3 4/6] fs: report " Amir Goldstein
2022-03-01 18:42 ` [PATCH v3 5/6] ovl: opt-in for " Amir Goldstein
2022-03-01 18:42 ` [PATCH v3 6/6] fuse: " Amir Goldstein
2022-03-02  6:59 ` [PATCH v3 0/6] Generic " Dave Chinner
2022-03-02  7:43   ` Amir Goldstein
2022-03-02  8:26     ` Dave Chinner
2022-03-02  8:34       ` Amir Goldstein
2022-03-02 16:59       ` Amir Goldstein
2022-03-02 21:12         ` Dave Chinner
2022-03-02 22:04           ` nfs generic/373 failure after "fs: allow cross-vfsmount reflink/dedupe" J. Bruce Fields
2022-03-02 22:26             ` Josef Bacik
2022-03-02 22:42               ` J. Bruce Fields
2022-03-02 23:45                 ` Josef Bacik
2022-03-03  0:07                   ` J. Bruce Fields
2022-03-03  0:29                     ` Josef Bacik
2022-03-03  0:50                       ` J. Bruce Fields [this message]
2022-03-04 20:03                         ` J. Bruce Fields
2022-03-03  6:50           ` [PATCH v3 0/6] Generic per-sb io stats Amir Goldstein

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=20220303005001.GB21944@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=chuck.lever@oracle.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nfs@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.