From: "J. Bruce Fields" <bfields@fieldses.org>
To: Olga Kornievskaia <kolga@netapp.com>
Cc: Christoph Hellwig <hch@lst.de>,
linux-fsdevel@vger.kernel.org,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
ng-linux-team <ng-linux-team@netapp.com>
Subject: Re: [PATCH v1 2/3] VFS permit cross device vfs_copy_file_range
Date: Tue, 21 Mar 2017 15:03:39 -0400 [thread overview]
Message-ID: <20170321190339.GE17872@fieldses.org> (raw)
In-Reply-To: <56CDE406-AE24-40E4-852C-1C47C5CCD37E@netapp.com>
On Tue, Mar 21, 2017 at 12:03:08PM -0400, Olga Kornievskaia wrote:
> Thank you for the update. I guess I don’t see how the proposed NFS
> implementation is complicated and ugly (but I’m biased). I’ll try to
> give you some performance number. My 1 data point (1gb) inter copy
> showed 30% improvement (how can that be ignored).
That would be useful, thanks--if it comes with some details about the
setup.
I'm not so curious about percent improvement, as how to predict the
performance on a given network.
If server-to-server copy looks like it's normally able to use close to
the available bandwidth between the two servers, and if a traditional
read-write-copy loop is similarly able to use the available bandwidth,
then I can figure out whether server-to-server copy will help on my
setup.
--b.
next prev parent reply other threads:[~2017-03-21 19:03 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-02 16:02 [PATCH v1 0/3] VFS changes for NFSv4.2 "inter" server-to-server COPY op Olga Kornievskaia
2017-03-02 16:02 ` [PATCH v1 1/3] fs: Don't copy beyond the end of the file Olga Kornievskaia
2017-03-02 16:58 ` Darrick J. Wong
2017-03-02 18:21 ` Olga Kornievskaia
2017-03-02 18:21 ` Olga Kornievskaia
2017-03-02 18:40 ` Darrick J. Wong
2017-03-07 23:43 ` Christoph Hellwig
2017-03-07 23:46 ` Olga Kornievskaia
2017-03-07 23:46 ` Olga Kornievskaia
2017-03-07 23:50 ` Christoph Hellwig
2017-03-08 15:39 ` Olga Kornievskaia
2017-03-08 15:39 ` Olga Kornievskaia
2017-03-08 15:57 ` Christoph Hellwig
2017-03-02 16:02 ` [PATCH v1 2/3] VFS permit cross device vfs_copy_file_range Olga Kornievskaia
2017-03-02 16:07 ` Christoph Hellwig
2017-03-02 16:38 ` Olga Kornievskaia
2017-03-02 16:38 ` Olga Kornievskaia
2017-03-07 20:35 ` Olga Kornievskaia
2017-03-07 20:35 ` Olga Kornievskaia
2017-03-15 18:09 ` J. Bruce Fields
2017-03-21 15:50 ` J. Bruce Fields
[not found] ` <56CDE406-AE24-40E4-852C-1C47C5CCD37E@netapp.com>
2017-03-21 19:03 ` J. Bruce Fields [this message]
2017-03-22 17:16 ` Olga Kornievskaia
2017-03-22 17:16 ` Olga Kornievskaia
2018-08-31 16:13 ` Florian Weimer
2018-08-31 16:25 ` Olga Kornievskaia
2018-08-31 22:56 ` Steve French
2017-03-02 16:02 ` [PATCH v1 3/3] VFS don't try clone if superblocks are different Olga Kornievskaia
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=20170321190339.GE17872@fieldses.org \
--to=bfields@fieldses.org \
--cc=hch@lst.de \
--cc=kolga@netapp.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=ng-linux-team@netapp.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 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.