All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Zach Brown <zab@redhat.com>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
	Anna Schumaker <Anna.Schumaker@netapp.com>,
	Christoph Hellwig <hch@infradead.org>,
	Jeff Layton <jlayton@poochiereds.net>,
	Trond Myklebust <trond.myklebust@primarydata.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
	linux-btrfs@vger.kernel.org,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	linux-scsi@vger.kernel.org
Subject: Re: [PATCH RFC 1/3] vfs: add copy_file_range syscall and vfs helper
Date: Tue, 14 Apr 2015 12:23:25 -0700	[thread overview]
Message-ID: <20150414192325.GB20599@infradead.org> (raw)
In-Reply-To: <20150414185408.GC23129@lenny.home.zabbo.net>

On Tue, Apr 14, 2015 at 11:54:08AM -0700, Zach Brown wrote:
> Is this relying on btrfs range cloning being atomic?  It certainly
> doesn't look atomic.  It can modify items across an arbitrarily large
> number of leaf blocks.  It can make the changes across multiple
> transactions which could introduce partial modification on reboot after
> crashes.  It can fail (the dynamic duo: enomem, eio) and leave the
> desintation partially modified.

I didn't mean atomic in the failure atomic sense, but in the sense of
being atomic vs other writes, similar to how Posix specifies it for
writes vs other writes.  Guess I need to express this intent better.

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
To: Zach Brown <zab-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: "J. Bruce Fields"
	<bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>,
	Anna Schumaker
	<Anna.Schumaker-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org>,
	Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	Jeff Layton <jlayton-vpEMnDpepFuMZCB2o+C8xQ@public.gmane.org>,
	Trond Myklebust
	<trond.myklebust-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org>,
	Linux Kernel Mailing List
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Linux FS-devel Mailing List
	<linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-btrfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Linux NFS Mailing List
	<linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH RFC 1/3] vfs: add copy_file_range syscall and vfs helper
Date: Tue, 14 Apr 2015 12:23:25 -0700	[thread overview]
Message-ID: <20150414192325.GB20599@infradead.org> (raw)
In-Reply-To: <20150414185408.GC23129-fypN+1c5dIyjpB87vu3CluTW4wlIGRCZ@public.gmane.org>

On Tue, Apr 14, 2015 at 11:54:08AM -0700, Zach Brown wrote:
> Is this relying on btrfs range cloning being atomic?  It certainly
> doesn't look atomic.  It can modify items across an arbitrarily large
> number of leaf blocks.  It can make the changes across multiple
> transactions which could introduce partial modification on reboot after
> crashes.  It can fail (the dynamic duo: enomem, eio) and leave the
> desintation partially modified.

I didn't mean atomic in the failure atomic sense, but in the sense of
being atomic vs other writes, similar to how Posix specifies it for
writes vs other writes.  Guess I need to express this intent better.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2015-04-14 19:23 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-10 22:00 [PATCH RFC 0/3] simple copy offloading system call Zach Brown
2015-04-10 22:00 ` [PATCH RFC 1/3] vfs: add copy_file_range syscall and vfs helper Zach Brown
2015-04-10 22:36   ` Trond Myklebust
2015-04-10 22:36     ` Trond Myklebust
2015-04-11  0:02     ` Zach Brown
2015-04-11  0:24       ` Trond Myklebust
2015-04-11 13:04         ` Jeff Layton
2015-04-13 16:32           ` Zach Brown
2015-04-14 16:53           ` Christoph Hellwig
2015-04-14 16:58             ` Christoph Hellwig
2015-04-14 17:16             ` Anna Schumaker
2015-04-14 17:16               ` Anna Schumaker
2015-04-14 17:16               ` Anna Schumaker
2015-04-14 18:19               ` J. Bruce Fields
2015-04-14 18:19                 ` J. Bruce Fields
2015-04-14 18:22                 ` Zach Brown
2015-04-14 18:22                   ` Zach Brown
2015-04-14 18:29                   ` J. Bruce Fields
2015-04-14 18:29                     ` J. Bruce Fields
2015-04-14 18:54                     ` Zach Brown
2015-04-14 18:54                       ` Zach Brown
2015-04-14 19:23                       ` Christoph Hellwig [this message]
2015-04-14 19:23                         ` Christoph Hellwig
2015-04-14 20:04                         ` Zach Brown
2015-04-14 20:04                           ` Zach Brown
2015-04-10 23:01   ` Andreas Dilger
2015-04-10 22:00 ` [PATCH RFC 2/3] x86: add sys_copy_file_range to syscall tables Zach Brown
2015-04-10 22:00 ` [PATCH RFC 3/3] btrfs: add .copy_file_range file operation Zach Brown
2015-04-14 17:08   ` Chris Mason
2015-04-14 17:08     ` Chris Mason
2015-05-06  6:15 ` [PATCH RFC 0/3] simple copy offloading system call Michael Kerrisk
2015-05-06  6:15   ` Michael Kerrisk
2015-05-07  2:52   ` Andy Lutomirski

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=20150414192325.GB20599@infradead.org \
    --to=hch@infradead.org \
    --cc=Anna.Schumaker@netapp.com \
    --cc=bfields@fieldses.org \
    --cc=jlayton@poochiereds.net \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=trond.myklebust@primarydata.com \
    --cc=zab@redhat.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.