similar to: send/receive and clone/clone_range ioctls

It seems that the BTRFS_IOC_CLONE ioctl fails when trying to do a cross-subvolume clone of a file. Chris Mason suggested in the past ([1]) that this should be possible. Am I missing something? [1] http://kerneltrap.org/mailarchive/linux-btrfs/2010/6/10/6884911 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to

Hi all, enclose a patch to improve the "btrfs subvolume find-new" command. This is a RFC because it is not finished, but it is an usable state and may be discussed. The aim of this patch is: - take in account not only an update of the extent but also an update of the inode and xattr (which includes the acl) - extract the generation reference number directly from a snapshot The new

Hello, This patch adds rollback support for the converter, the converter can roll back a conversion if the image file haven't been modified. In addition, I rearrange some codes in convert.c and add a few comments. Regards YZ --- diff -r 12138d4beeb0 convert.c --- a/convert.c Fri Jan 04 11:29:55 2008 -0500 +++ b/convert.c Mon Jan 07 23:35:25 2008 +0800 @@ -33,6 +33,7 @@ #include

The CLONE and CLONE_RANGE ioctls round up the range of extents being cloned to the block size when the range to clone extends to the end of file (this is always the case with CLONE). It was then using that offset when extending the destination file''s i_size. Fix this by not setting i_size beyond the originally requested ending offset. This bug was introduced by a22285a6 (2.6.35-rc1).

On Fri, Oct 28, 2016 at 01:00:24AM +0200, Saint Germain via samba wrote: > > On Thu, 27 Oct 2016 15:39:27 -0700, Jeremy Allison <jra at samba.org> > wrote : > > > On Fri, Oct 28, 2016 at 12:08:50AM +0200, Saint Germain via samba > > wrote: > > > On Thu, 27 Oct 2016 14:50:48 -0700, Jeremy Allison <jra at samba.org> > > > wrote : > > >

I want to make you aware of a possible bug in the reflink handling of btrfs: When I reflink a file larger 2GB (on the same subvol), the reflinking fails. But it works fine for files smaller 2GB in size. I was able to track this down to btrfs with great support of Martin Raiber who created a small demo code: Source: https://urbackup.atlassian.net/secure/attachment/10201/reflink.cpp Compile: g++

On Thu, 27 Oct 2016 16:27:05 -0700, Jeremy Allison <jra at samba.org> wrote : > On Fri, Oct 28, 2016 at 01:00:24AM +0200, Saint Germain via samba > wrote: > > > > On Thu, 27 Oct 2016 15:39:27 -0700, Jeremy Allison <jra at samba.org> > > wrote : > > > > > On Fri, Oct 28, 2016 at 12:08:50AM +0200, Saint Germain via samba > > > wrote:

On Thu, 27 Oct 2016 14:50:48 -0700, Jeremy Allison <jra at samba.org> wrote : > On Thu, Oct 27, 2016 at 11:27:29PM +0200, Saint Germain via samba > wrote: > > Hello, > > > > I would like to test Samba server-side copy with BTRFS: > > https://wiki.samba.org/index.php/Server-Side_Copy#Btrfs_Enhanced_Server-Side_Copy_Offload > > > > However it is not

Hi there, after my filesystem is broken (I have no idea why, because last shut down was nomal) I tried to repair it with btrfsck ( Btrfs v0.20-rc1-56-g6cd836d). But unfortunately the process breaks with: parent transid verify failed on 29896704 wanted 392661 found 395689 parent transid verify failed on 29896704 wanted 392661 found 395689 parent transid verify failed on 29896704 wanted 392661

fs_info->last_trans_log_full_commit is a 64bits variant, we might get a wrong value on the 32bit machines if we access it directly. Fix it by atomic operation. Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com> Signed-off-by: Miao Xie <miaox@cn.fujitsu.com> --- fs/btrfs/ctree.h | 2 +- fs/btrfs/extent-tree.c | 3 ++- fs/btrfs/inode.c | 3 ++- fs/btrfs/tree-log.c |

This patch adds mixed back ref support for btrfs programs. The mixed back ref is a new disk format. back compatilibity is still not implemented. To try the new disk format, you need fresh formatted btrfs. Signed-off-by: Yan Zheng <zheng.yan@oracle.com> --- diff -urp btrfs-progs-unstable/crc32c.h btrfs-progs-2/crc32c.h --- btrfs-progs-unstable/crc32c.h 2008-09-30 16:50:58.898877720 +0800

Hello Developers, it seems that i discovered a bug in btrfs while testing it on a zSeries mainframe :-) ## Test environment: - IBM System z900 Mainframe - Debian SID with 64 Bit Kernel - GIT Sources from git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable.git - System runs as z/VM guest - 3 Virtual CPUs - 1 GB RAM Storage ## Initial Test Setup - Setup a Debian SID System with

Hello, I''d like to know if there has been any discussion about adding a new feature to write (add) data at an offset, but without overwriting existing data, or re-writing the existing data. Essentially, in-place addition/removal of data to a file at a place other than the end of the file. Some possible use-cases of such a feature would be: (a) Databases (currently hack around this by

I have a corrupted multi-device file system that got corrupted ages ago (as I recall, one of the drives stopped responding, causing btrfs to panic). I am hoping to recover some of the data. For what it''s worth, here is the dmesg output from trying to mount the file system on a 3.0 kernel: device label Media devid 6 transid 816153 /dev/sdq device label Media devid 7 transid 816153

So I''m having a bit of trouble with one of my btrfs filesystems. It isn''t mounting after a power failure. I can''t get restore or btrfsck to run, even on backup supers. I''ve pasted some output below. My btrfs-progs below come from git this morning, running on linux 3.2.0. # mount /dev/md2 /media/test/ mount: wrong fs type, bad option, bad superblock on

Hi, I''m having a filesystem that''s been a bit mangled by external causes, so I thought I''d see how much I could salvage (it''s not critical, though). Thus, I pulled btrfsck from git and ran: pannekake:~/btrfs-progs# ./btrfsck --repair /dev/mapper/pannekake-backup-btrfs It spit out a ton of warnings like these (I can get the whole log if you''re

My raid5 crashed, so i changed the old hdd and started the rebuild. But now i can''t mount the btrfs, the mount command frozen and the kernel give me in a loop the follwing lines: Jul 29 18:37:04 fileserver kernel: [ 1229.692268] verify_parent_transid: 2492 callbacks suppressed Jul 29 18:37:04 fileserver kernel: [ 1229.692274] parent transid verify failed on 6975016271872 wanted 204247

No material changes are made. --- Makefile | 10 +- convert.c => convert/convert.c | 803 +--------------------------------------- convert/convert.h | 76 ++++ convert/ext2.c | 791 +++++++++++++++++++++++++++++++++++++++ 4 files changed, 873 insertions(+), 807 deletions(-) rename convert.c => convert/convert.c (74%) create mode

Hi, I reported a bug to anaconda (rhbz 901905), but it might be btfs related. Anaconda does this: 18:49:10,317 INFO program: Running... mkfs.btrfs --data=single --label=fedora /dev/vdb1 /dev/vdc1 /dev/vdd1 /dev/vde1 18:49:10,742 INFO program: 18:49:10,746 INFO program: WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL 18:49:10,746 INFO program: WARNING! - see http://btrfs.wiki.kernel.org before

Hi again. Sorry for top posting. I have a 9 disk filesystem that does not mount anymore and need some help/advice so I can recover the data. What happened was that I was running a btrfs delete device under Ubuntu 13.04 Kernel 3.8 and after a long time of moving data around it crashed with a SEGV. Now the filesystem does not mount and none of the recovery options I have tried work. I have