Re: [PATCH 0/2] btrfs: allow cross-subvolume BTRFS_IOC_CLONE
Is there any reason why this can't be applied in for-linus? Does it need more testing? Still no corruption here after copying the whole root FS in subvolume after btrfs-convert, this FS is used everyday with big image files, clients backups of Windows directories (small files) and 3 snapshots a day, using cp --reflink for whole image copy to test recovery and more. BTRFS is the only module I need to recompile on this machine after each upgrading the kernel to apply this patch. On Mon, Jan 9, 2012 at 8:31 AM, Jérôme Poulin jeromepou...@gmail.com wrote: On Mon, Jan 9, 2012 at 1:58 AM, Marios Titas redneb8...@gmail.com wrote: The simple case of 'cp --reflink' works fine [...] It doesn't work here: cp: failed to clone `/tmp/test': Invalid cross-device link That's with 3.1 + for-linus. This is the problem, it doesn't work because you have to apply the patch at http://permalink.gmane.org/gmane.comp.file-systems.btrfs/9865 which is not mainlined yet. This patch dates back from March 31st, I have been using it since it was released. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] btrfs: allow cross-subvolume BTRFS_IOC_CLONE
On Mon, Jan 9, 2012 at 1:58 AM, Marios Titas redneb8...@gmail.com wrote: The simple case of 'cp --reflink' works fine [...] It doesn't work here: cp: failed to clone `/tmp/test': Invalid cross-device link That's with 3.1 + for-linus. This is the problem, it doesn't work because you have to apply the patch at http://permalink.gmane.org/gmane.comp.file-systems.btrfs/9865 which is not mainlined yet. This patch dates back from March 31st, I have been using it since it was released. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] btrfs: allow cross-subvolume BTRFS_IOC_CLONE
On Fri, Jan 6, 2012 at 12:57, David Sterba d...@jikos.cz wrote: On Fri, Jan 06, 2012 at 02:04:12PM +0200, Konstantinos Skarlatos wrote: Me too wants cp --reflink across subvolumes. Please make this feature available to us, as its a poor man's dedupe and would give big space savings for many use cases. The simple case of 'cp --reflink' works fine [...] It doesn't work here: cp: failed to clone `/tmp/test': Invalid cross-device link That's with 3.1 + for-linus. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] btrfs: allow cross-subvolume BTRFS_IOC_CLONE
On 22/12/2011 2:24 μμ, Chris Samuel wrote: Christoph, On Sat, 2 Apr 2011 12:40:11 AM Chris Mason wrote: Excerpts from Christoph Hellwig's message of 2011-04-01 09:34:05 -0400: I don't think it's a good idea to introduce any user visible operations over subvolume boundaries. Currently we don't have any operations over mount boundaries, which is pretty fumdamental to the unix filesystem semantics. If you want to change this please come up with a clear description of the semantics and post it to linux-fsdevel for discussion. That of course requires a clear description of the btrfs subvolumes, which is still completely missing. The subvolume is just a directory tree that can be snapshotted, and has it's own private inode number space. reflink across subvolumes is no different from copying a file from one subvolume to another at the VFS level. The src and destination are different files and different inodes, they just happen to share data extents. Were Chris Mason's points above enough to sway your opposition to this functionality/patch? There is demand for the ability to move data between subvolumes without needing to copy the extents themselves, it's cropped up again on the list in recent days. It seems a little hard (and counterintuitive) to enforce a wasteful use of resources to copy data between different parts of the same filesystem which happen to be a on a different subvolume when it's permitted functional to the same filesystem on the same subvolume. I don't dispute the comment about documentation on subvolumes though, there is a short discussion of them on the btrfs wiki in the sysadmins guide, but not really a lot of detail. :-) All the best, Chris Me too wants cp --reflink across subvolumes. Please make this feature available to us, as its a poor man's dedupe and would give big space savings for many use cases. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] btrfs: allow cross-subvolume BTRFS_IOC_CLONE
On Fri, Jan 06, 2012 at 02:04:12PM +0200, Konstantinos Skarlatos wrote: Me too wants cp --reflink across subvolumes. Please make this feature available to us, as its a poor man's dedupe and would give big space savings for many use cases. The simple case of 'cp --reflink' works fine, the only remaining case is the unimplemented clone of part of a compressed inline extent. And it has to be: * at least 2 blocks uncompressed * the cloned range does not span the whole extent The ioctl needs ranges and length aligned up to blocksize, ie. 4096, cloning of short inline extents work. The missing case can be reproduced with this: --- #!/bin/sh # assume, that fs is mounted with compression on src=test-clone-compressed-inline dd if=/dev/zero of=$src bs=1K count=3 oflag=sync sync filefrag -vbs $src clone_range $src 4096 4096 subvol2/$src-dest0 0 clone_range $src 4096 4096 subvol2/$src-dest4096 4096 clone_range $src 4096 4096 subvol2/$src-dest8192 8192 --- $ ./test-clone-range-inline 3+0 records in 3+0 records out 3072 bytes (3.1 kB) copied, 0.0487466 s, 63.0 kB/s Filesystem type is: 9123683e File size of test-clone-compressed-inline is 3072 (3 blocks, blocksize 1024) ext logical physical expected length flags 0 004096 not_aligned,inline,eof test-clone-compressed-inline: 1 extent found clone_range test-clone-compressed-inline 3 4096~4096 to subvol2/test-clone-compressed-inline-dest0 4 0 = -1 Invalid argument clone_range test-clone-compressed-inline 3 4096~4096 to subvol2/test-clone-compressed-inline-dest4096 4 4096 = -1 Invalid argument clone_range test-clone-compressed-inline 3 4096~4096 to subvol2/test-clone-compressed-inline-dest8192 4 8192 = -1 Invalid argument --- This does not work on a single subvolume, so extending clone to span subvolumes should not break anything that hasn't been broken already. david -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] btrfs: allow cross-subvolume BTRFS_IOC_CLONE
Christoph, On Sat, 2 Apr 2011 12:40:11 AM Chris Mason wrote: Excerpts from Christoph Hellwig's message of 2011-04-01 09:34:05 -0400: I don't think it's a good idea to introduce any user visible operations over subvolume boundaries. Currently we don't have any operations over mount boundaries, which is pretty fumdamental to the unix filesystem semantics. If you want to change this please come up with a clear description of the semantics and post it to linux-fsdevel for discussion. That of course requires a clear description of the btrfs subvolumes, which is still completely missing. The subvolume is just a directory tree that can be snapshotted, and has it's own private inode number space. reflink across subvolumes is no different from copying a file from one subvolume to another at the VFS level. The src and destination are different files and different inodes, they just happen to share data extents. Were Chris Mason's points above enough to sway your opposition to this functionality/patch? There is demand for the ability to move data between subvolumes without needing to copy the extents themselves, it's cropped up again on the list in recent days. It seems a little hard (and counterintuitive) to enforce a wasteful use of resources to copy data between different parts of the same filesystem which happen to be a on a different subvolume when it's permitted functional to the same filesystem on the same subvolume. I don't dispute the comment about documentation on subvolumes though, there is a short discussion of them on the btrfs wiki in the sysadmins guide, but not really a lot of detail. :-) All the best, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part.
Re: [PATCH 0/2] btrfs: allow cross-subvolume BTRFS_IOC_CLONE
On Fri, 2011-04-01 at 09:34 -0400, Christoph Hellwig wrote: On Thu, Mar 31, 2011 at 08:02:22AM -0400, Chris Mason wrote: Excerpts from Christoph Hellwig's message of 2011-03-31 02:36:36 -0400: On Thu, Mar 31, 2011 at 12:00:11AM -0400, Larry D'Anna wrote: This is a simple patch to allow reflinks to be made crossing subvolume boundaries. NAK. subvolumes will have to become vfsmounts sooner or later, and we really must not support any operations spanning mountpoints. Sorry, I disagree here. reflinks were always intended to be able to span subvolumes. There's no conflict at all because they span different inodes. I don't think it's a good idea to introduce any user visible operations over subvolume boundaries. Currently we don't have any operations over mount boundaries, which is pretty fumdamental to the unix filesystem semantics. If you want to change this please come up with a clear description of the semantics and post it to linux-fsdevel for discussion. That of course requires a clear description of the btrfs subvolumes, which is still completely missing. I don't really understand the details here, but doesn't the creation of a snapshot already lead to data extents being shared between sub-volumes? From a simple user perspective this sounds like a very useful capability. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] btrfs: allow cross-subvolume BTRFS_IOC_CLONE
* Ken Drummond (bt...@kendrummond.com) [110402 11:51]: I don't really understand the details here, but doesn't the creation of a snapshot already lead to data extents being shared between sub-volumes? From a simple user perspective this sounds like a very useful capability. I was surprised and frustrated to find it missing. I had just copied a large quantity of data into btrfs, realized i need to make a subvolume to try out snapshotting, and then found out i had to copy all the data *again* to get it into a subvolume. There are tons of scenarios where users will want and expect to be able to do this. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] btrfs: allow cross-subvolume BTRFS_IOC_CLONE
I am very happy to see this patch. It was one of the first thing I tried after making a subvolume, cp --reflink, and it failed. I'll have to try this out. Jérôme Poulin On 2011-04-02, at 12:56, Larry D'Anna la...@elder-gods.org wrote: * Ken Drummond (bt...@kendrummond.com) [110402 11:51]: I don't really understand the details here, but doesn't the creation of a snapshot already lead to data extents being shared between sub-volumes? From a simple user perspective this sounds like a very useful capability. I was surprised and frustrated to find it missing. I had just copied a large quantity of data into btrfs, realized i need to make a subvolume to try out snapshotting, and then found out i had to copy all the data *again* to get it into a subvolume. There are tons of scenarios where users will want and expect to be able to do this. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] btrfs: allow cross-subvolume BTRFS_IOC_CLONE
On Thu, Mar 31, 2011 at 08:02:22AM -0400, Chris Mason wrote: Excerpts from Christoph Hellwig's message of 2011-03-31 02:36:36 -0400: On Thu, Mar 31, 2011 at 12:00:11AM -0400, Larry D'Anna wrote: This is a simple patch to allow reflinks to be made crossing subvolume boundaries. NAK. subvolumes will have to become vfsmounts sooner or later, and we really must not support any operations spanning mountpoints. Sorry, I disagree here. reflinks were always intended to be able to span subvolumes. There's no conflict at all because they span different inodes. I don't think it's a good idea to introduce any user visible operations over subvolume boundaries. Currently we don't have any operations over mount boundaries, which is pretty fumdamental to the unix filesystem semantics. If you want to change this please come up with a clear description of the semantics and post it to linux-fsdevel for discussion. That of course requires a clear description of the btrfs subvolumes, which is still completely missing. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] btrfs: allow cross-subvolume BTRFS_IOC_CLONE
On Fri, Apr 1, 2011 at 8:40 PM, Chris Mason chris.ma...@oracle.com wrote: Excerpts from Christoph Hellwig's message of 2011-04-01 09:34:05 -0400: I don't think it's a good idea to introduce any user visible operations over subvolume boundaries. Currently we don't have any operations over mount boundaries, which is pretty fumdamental to the unix filesystem semantics. If you want to change this please come up with a clear description of the semantics and post it to linux-fsdevel for discussion. That of course requires a clear description of the btrfs subvolumes, which is still completely missing. The subvolume is just a directory tree that can be snapshotted, and has it's own private inode number space. reflink across subvolumes is no different from copying a file from one subvolume to another at the VFS level. The src and destination are different files and different inodes, they just happen to share data extents. ... and currently copying file from one subvolume to another requires copying the data as well. It'd be great if you could only copy the metadata. A good possible use that comes to mind is to quickly merge several subvolumes into a new one. -- Fajar -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] btrfs: allow cross-subvolume BTRFS_IOC_CLONE
On Thu, Mar 31, 2011 at 12:00:11AM -0400, Larry D'Anna wrote: This is a simple patch to allow reflinks to be made crossing subvolume boundaries. NAK. subvolumes will have to become vfsmounts sooner or later, and we really must not support any operations spanning mountpoints. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] btrfs: allow cross-subvolume BTRFS_IOC_CLONE
On 31.03.2011 08:36, Christoph Hellwig wrote: On Thu, Mar 31, 2011 at 12:00:11AM -0400, Larry D'Anna wrote: This is a simple patch to allow reflinks to be made crossing subvolume boundaries. NAK. subvolumes will have to become vfsmounts sooner or later, and we really must not support any operations spanning mountpoints. In what way would this interfere? the reflinked file gets its own inum in its own mountpoint. The two files only internally share some disk space. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] btrfs: allow cross-subvolume BTRFS_IOC_CLONE
Excerpts from Christoph Hellwig's message of 2011-03-31 02:36:36 -0400: On Thu, Mar 31, 2011 at 12:00:11AM -0400, Larry D'Anna wrote: This is a simple patch to allow reflinks to be made crossing subvolume boundaries. NAK. subvolumes will have to become vfsmounts sooner or later, and we really must not support any operations spanning mountpoints. Sorry, I disagree here. reflinks were always intended to be able to span subvolumes. There's no conflict at all because they span different inodes. -chris -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
