[PATCH 2/3] btrfs: allocate root item at snapshot ioctl time

The actual snapshot creation is delayed until transaction commit. If we cannot get enough memory for the root item there, we have to fail the whole transaction commit which is bad. So we'll allocate the memory at the ioctl call and pass it along with the pending_snapshot struct. The potential

[PATCH 3/3] btrfs: preallocate path for snapshot creation at ioctl time

We can also preallocate btrfs_path that's used during pending snapshot creation and avoid another late ENOMEM failure. Signed-off-by: David Sterba --- fs/btrfs/ioctl.c | 4 +++- fs/btrfs/transaction.c | 9 - fs/btrfs/transaction.h | 1 + 3 files changed, 8

[PATCH 1/3] btrfs: do an allocation earlier during snapshot creation

We can allocate pending_snapshot earlier and do not have to do cleanup in case of failure. Signed-off-by: David Sterba --- fs/btrfs/ioctl.c | 20 +--- 1 file changed, 9 insertions(+), 11 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index

[PATCH 0/3] Reduced impact of allocation failures during snapshot creation

Here's an improvement in allocation of temporary structures during snaphost creation, namely the root_item. The allocation is moved to the ioctl call, so it will fail early and not during the transaction commit. I've once hit it in practice. It's aimed for 4.5 dev cycle and can be pulled from

[PATCH v9 2/4] x86: add sys_copy_file_range to syscall tables

From: Zach Brown Add sys_copy_file_range to the x86 syscall tables. Signed-off-by: Zach Brown [Anna Schumaker: Update syscall number in syscall_32.tbl] Signed-off-by: Anna Schumaker Reviewed-by: Christoph Hellwig ---

[PATCH v9 3/4] btrfs: add .copy_file_range file operation

From: Zach Brown This rearranges the existing COPY_RANGE ioctl implementation so that the .copy_file_range file operation can call the core loop that copies file data extent items. The extent copying loop is lifted up into its own function. It retains the core btrfs error

[PATCH v9 1/4] vfs: add copy_file_range syscall and vfs helper

From: Zach Brown Add a copy_file_range() system call for offloading copies between regular files. This gives an interface to underlying layers of the storage stack which can copy without reading and writing all the data. There are a few candidates that should support copy

[PATCH v9 4/4] vfs: Add vfs_copy_file_range() support for pagecache copies

This allows us to have an in-kernel copy mechanism that avoids frequent switches between kernel and user space. This is especially useful so NFSD can support server-side copies. The default (flags=0) means to first attempt copy acceleration, but use the pagecache if that fails. Signed-off-by:

[PATCH v9 0/4] VFS: In-kernel copy system call

Copy system calls came up during Plumbers a while ago, mostly 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 his patches upstream so individual filesystems don't

Re: [PATCH] btrfs-progs: Fix partitioned loop devices resolve.

On 11/09/2015 03:12 PM, Karel Zak wrote: > On Mon, Nov 09, 2015 at 02:06:26PM +0100, Florian Margaine wrote: >> Instead of using string functions to extract the device name and reading >> this file, this patch uses the loop device API through ioctl to get the >> correct backing file. > >

re: btrfs: add tracing for failed reservations

[ This is old. I don't know why it's only complaining now. Anyway this looks like one of those rarely used code paths so it might be a real bug. ] Hello Jeff Mahoney, The patch cab45e22da48: "btrfs: add tracing for failed reservations" from Oct 16, 2013, leads to the following static

Re: Ideas for btrfs-convert fix(or rework)

On Tue, 10 Nov 2015 16:16:26 +0800 Qu Wenruo wrote: > So if things are correct, the btrfs you converted should still be in > mixed-bg mode. > A recent 'btrfs fi df' command should show things like: > Data+Metadata, DUP: total=512.00MiB, used=68.23MiB Actually not quite.

Re: [patch] Btrfs: tests: checking for NULL instead of IS_ERR()

On Tue, Nov 10, 2015 at 12:10:03PM +0300, Dan Carpenter wrote: > btrfs_alloc_dummy_root() return an error pointer on failure, it never > returns NULL. > > Signed-off-by: Dan Carpenter Reviewed-by: David Sterba -- To unsubscribe from this list: send

Re: Ideas for btrfs-convert fix(or rework)

Qu Wenruo posted on Tue, 10 Nov 2015 17:18:02 +0800 as excerpted: > Yes, some problem can be fixed by such balance, as after balance, data > and metadata will be relocated to correct new chunks. > > But there may be a lot of hidden bugs here. > And we can't ignore such malfunction just because

btrfs-balance convert from raid1 to single on specific device?

Hi, I'm running Kernel 4.3 and Btrfs-tools 4.3 on Debian Jessie. I compiled the tools and kernel myself. Recently I added a new disk to my btrfs volume and wanted to proceed to convert from single to raid1. Unfortunately the new disk seems to be faulty and started throwing a lot of errors. The

[patch] Btrfs: tests: checking for NULL instead of IS_ERR()

btrfs_alloc_dummy_root() return an error pointer on failure, it never returns NULL. Signed-off-by: Dan Carpenter diff --git a/fs/btrfs/tests/free-space-tests.c b/fs/btrfs/tests/free-space-tests.c index c8c3d70..8b72b00 100644 --- a/fs/btrfs/tests/free-space-tests.c

Re: Ideas for btrfs-convert fix(or rework)

Roman Mamedov wrote on 2015/11/10 14:08 +0500: On Tue, 10 Nov 2015 16:16:26 +0800 Qu Wenruo wrote: So if things are correct, the btrfs you converted should still be in mixed-bg mode. A recent 'btrfs fi df' command should show things like: Data+Metadata, DUP:

Re: Ideas for btrfs-convert fix(or rework)

Roman Mamedov wrote on 2015/11/10 12:55 +0500: On Tue, 10 Nov 2015 14:27:41 +0800 Qu Wenruo wrote: But without such work, btrfs-convert will always be a mess and no real support for balance. I wonder, what happened to the current btrfs-convert? Perhaps a

Re: [PATCH] btrfs-progs: Fix partitioned loop devices resolve.

On Tue, Nov 10, 2015 at 09:35:22AM +0100, Florian Margaine wrote: > > > On 11/09/2015 03:12 PM, Karel Zak wrote: > > On Mon, Nov 09, 2015 at 02:06:26PM +0100, Florian Margaine wrote: > >> Instead of using string functions to extract the device name and reading > >> this file, this patch uses the

Re: [PATCH 00/15] btrfs: Hot spare and Auto replace

On 2015-11-09 16:29, Duncan wrote: Austin S Hemmelgarn posted on Mon, 09 Nov 2015 09:09:07 -0500 as excerpted: btrfs fi show Label: none uuid: 52f170c1-725c-457d-8cfd-d57090460091 Total devices 2 FS bytes used 112.00KiB devid1 size 2.00GiB used 417.50MiB path /dev/sdc

Re: btrfs-progs send | receive error: no such file or directory

On 2015-11-09 22:11, Glen H wrote: On Mon, Nov 9, 2015 at 8:50 AM, Austin S Hemmelgarn wrote: On 2015-11-08 16:28, Glen H wrote: Hi, I really enjoy the features of btrfs but send|receive is failing me so my backups are not working. I'm using "btrbk" to backup my

Re: btrfs-balance convert from raid1 to single on specific device?

Hi again, I've been browsing through the mailing list and I came across a patch that might solve my issue a lot easier. Specifically "[PATCH 02/15] btrfs: Do per-chunk check for mount time check" by Qu Wenruo I'm a bit at a loss as to how to apply that patch. Since I'm not even sure for which

Re: btrfs: add tracing for failed reservations

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/10/15 4:08 AM, Dan Carpenter wrote: > [ This is old. I don't know why it's only complaining now. Anyway > this looks like one of those rarely used code paths so it might be > a real bug. ] > > Hello Jeff Mahoney, > > The patch cab45e22da48:

Re: [PATCH v9 0/4] VFS: In-kernel copy system call

On Tue, Nov 10, 2015 at 04:53:29PM -0500, Anna Schumaker wrote: > Copy system calls came up during Plumbers a while ago, mostly 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 >

RE: [PATCH 1/3] btrfs-progs: cmds-device: use warning/error for error message

Hi, Anand Jain > -Original Message- > From: Anand Jain [mailto:anand.j...@oracle.com] > Sent: Monday, November 09, 2015 6:34 PM > To: Zhao Lei > Cc: linux-btrfs@vger.kernel.org; dste...@suse.cz > Subject: Re: [PATCH 1/3] btrfs-progs: cmds-device: use warning/error