Re: [PATCH v7 5/4] copy_file_range.2: New page documenting copy_file_range()

On 26/10/15 03:39, Christoph Hellwig wrote: > On Sat, Oct 24, 2015 at 01:02:21PM +0100, P??draig Brady wrote: >> I'm a bit worried about the sparse expansion and default reflinking >> which might preclude cp(1) from using this call in most cases, but I will >> test and try to use it. coreutils has

Re: [PATCH v7 5/4] copy_file_range.2: New page documenting copy_file_range()

On 23/10/15 20:32, Anna Schumaker wrote: > +len = stat.st_size; > + > +fd_out = open(argv[2], O_CREAT|O_WRONLY|O_TRUNC, 0644); > +if (fd_out == \-1) { > +perror("open (argv[2])"); > +exit(EXIT_FAILURE); > +} > + > +do { > +ret = copy_file_range(fd_in,

Re: [PATCH v6 5/4] copy_file_range.2: New page documenting copy_file_range()

It's probably worth mentioning the sparse expansion caveat in the docs, as it's important and not obvious. I.E. copy_file_range() could be called from, but would still benefit from a user space app using a SEEK_{HOLE,DATA} loop. thanks, Pádraig. -- To unsubscribe from this list: send the line

Re: [PATCH v5 8/9] vfs: Add vfs_copy_file_range() support for pagecache copies

On 16/10/15 12:46, Austin S Hemmelgarn wrote: > On 2015-10-16 01:38, Christoph Hellwig wrote: >> On Thu, Oct 15, 2015 at 08:24:51AM -0400, Austin S Hemmelgarn wrote: >>> My only point with saying we shouldn't reflink by default is that there are >>> many (unintelligent) people who will assume that

Re: [PATCH v5 8/9] vfs: Add vfs_copy_file_range() support for pagecache copies

On 14/10/15 20:14, Austin S Hemmelgarn wrote: > On 2015-10-14 14:53, Andy Lutomirski wrote: >> On Wed, Oct 14, 2015 at 11:49 AM, Christoph Hellwig >> wrote: >>> On Wed, Oct 14, 2015 at 11:38:13AM -0700, Andy Lutomirski wrote: One might argue that reflink is like copy +

Re: [PATCH v5 9/9] btrfs: btrfs_copy_file_range() only supports reflinks

On 11/10/15 15:29, Christoph Hellwig wrote: > On Wed, Sep 30, 2015 at 01:26:53PM -0400, Anna Schumaker wrote: >> Reject copies that don't have the COPY_FR_REFLINK flag set. > > I think a reflink actually is a perfectly valid copy, and I don't buy > the duplicate arguments in earlier threads. We

Re: [PATCH v5 8/9] vfs: Add vfs_copy_file_range() support for pagecache copies

On 08/10/15 02:40, Neil Brown wrote: > Anna Schumaker writes: > >> @@ -1338,34 +1362,26 @@ ssize_t vfs_copy_file_range(struct file *file_in, >> loff_t pos_in, >> struct file *file_out, loff_t pos_out, >> size_t len,

Re: [PATCH v3 8/9] vfs: copy_file_range() can do a pagecache copy with splice

moved the rw_verify_area() calls into the fallback code since some > filesystems can handle reflinking a large range. > > Signed-off-by: Anna Schumaker <anna.schuma...@netapp.com> Reviewed-by: Pádraig Brady <p...@draigbrady.com> LGTM. For my reference, for cp(1), mv(1), install(1)

Re: [PATCH v2 10/9] copy_file_range.2: New page documenting copy_file_range()

On 22/09/15 21:10, Anna Schumaker wrote: > On 09/14/2015 02:32 PM, Darrick J. Wong wrote: >> On Sun, Sep 13, 2015 at 09:50:18AM +0200, Michael Kerrisk (man-pages) wrote: >>> Hi Anna, >>> Furthermore, I even wonder if explicitly specifying flags as >>> COPY_FR_COPY | COPY_FR_REFLINK should just

Re: [PATCH v1 0/8] VFS: In-kernel copy system call

On 08/09/15 20:10, Andy Lutomirski wrote: > On Tue, Sep 8, 2015 at 11:23 AM, Anna Schumaker > <anna.schuma...@netapp.com> wrote: >> On 09/08/2015 11:21 AM, Pádraig Brady wrote: >>> I see copy_file_range() is a reflink() on BTRFS? >>> That's a bit surprisi

Re: [PATCH v1 0/8] VFS: In-kernel copy system call

On 04/09/15 21:16, Anna Schumaker wrote: > Copy system calls came up during Plumbers a couple of weeks ago, because > several filesystems (including NFS and XFS) are currently working on copy > acceleration implementations. We haven't heard from Zach Brown in a while, > so I volunteered to push

Re: System Storage Manager

On 12/07/2011 10:20 AM, Lukas Czerner wrote: Hello everyone, I would like to introduce to you a new tool called System Storage Manager (ssm). It is supposed to provide easy to use command line interface to manage your storage using various technologies like lvm, btrfs, encrypted volumes and

Re: [PATCH] xfstests 255: add a seek_data/seek_hole tester

On 08/31/2011 05:43 AM, Sunil Mushran wrote: On 8/30/2011 8:29 PM, Dave Chinner wrote: And that's -exactly- the ambiguous, vague definition that has raised all these questions in the first place. I was in doubt about whether unwritten extents can be considered a hole, and by your definition

Re: [PATCH] xfstests 255: add a seek_data/seek_hole tester

On 29/06/11 08:40, Christoph Hellwig wrote: On Wed, Jun 29, 2011 at 04:53:07PM +1000, Dave Chinner wrote: On Tue, Jun 28, 2011 at 11:33:19AM -0400, Josef Bacik wrote: This is a test to make sure seek_data/seek_hole is acting like it does on Solaris. It will check to see if the fs supports

Re: [PATCH] xfstests 255: add a seek_data/seek_hole tester

On 29/06/11 18:29, Sunil Mushran wrote: On 06/29/2011 03:42 AM, Pádraig Brady wrote: There is the argument, that if this interface can distinguish these dirty unwritten extents, then why can't the fiemap interface too? The advantage of the fiemap interface is that it can distinguish empty

Re: btrfs: compression breaks cp and cross-FS mv, FS_IOC_FIEMAP bug?

On 14/02/11 17:58, Marti Raudsepp wrote: On Mon, Feb 14, 2011 at 17:01, Chris Mason chris.ma...@oracle.com wrote: Or, it could just be delalloc ;) I suspect delalloc. After creating the file, filefrag reports 1 extent found, but for some reason it doesn't actually print out details of the

Re: VFS support for fast copy on deduplicating FSes

On 25/11/10 10:32, Tomasz Torcz wrote: On Thu, Nov 25, 2010 at 04:19:17AM -0600, David Nicol wrote: unresearched question/suggestion: Is there general support for a fast copy ioctl in the VFS layer, which would be hooked by file systems that support COW or other forms of deduplication and

Re: [PATCH 4/6] Ext4: fail if we try to use hole punch

On 15/11/10 17:05, Josef Bacik wrote: Ext4 doesn't have the ability to punch holes yet, so make sure we return EOPNOTSUPP if we try to use hole punching through fallocate. This support can be added later. Thanks, Signed-off-by: Josef Bacik jo...@redhat.com --- fs/ext4/extents.c |4

Re: A file cloned with cp --reflink different from the original one?

Jian Lin wrote: 2009/11/23 Pádraig Brady p...@draigbrady.com: Jian Lin wrote: I installed BtrFS 0.19 and GNU coreutils 8.1 on my Ubuntu 9.10. I tried to clone some files with cp --reflink to make them copy-on-write. However, I found some of the files cloned have different MD5s

Re: BTRFS file clone support for cp

Chris Mason wrote: On Tue, Jul 28, 2009 at 10:06:35PM +0200, Giuseppe Scrivano wrote: I can't replicate it now, all tests I am doing report that blocks used before and after the clone are the same. Probably yesterday the difference I noticed was in reality the original file flushed to the

Re: BTRFS file clone support for cp

Giuseppe Scrivano wrote: Jim Meyering j...@meyering.net writes: Another possible issue with this I can think of is depending on the modification pattern of the COW files, the modification processes could fragment the file or more seriously be given ENOSPC errors. I hope btrfs takes care of