Re: [PATCH v2 0/5] Make btrfs-progs really compatible with any kernel version

Liu Bo wrote on 2015/12/03 18:53 -0800: On Fri, Dec 04, 2015 at 10:08:35AM +0800, Qu Wenruo wrote: Liu Bo wrote on 2015/12/03 17:44 -0800: On Mon, Nov 23, 2015 at 06:56:09PM +0100, David Sterba wrote: On Mon, Nov 23, 2015 at 08:56:13PM +0800, Anand Jain wrote: Btrfs-progs is a tool for

[PATCH 3/4] nfsd: Pass filehandle to nfs4_preprocess_stateid_op()

From: Anna Schumaker This will be needed so COPY can look up the saved_fh in addition to the current_fh. Signed-off-by: Anna Schumaker Signed-off-by: Christoph Hellwig Acked-by: J. Bruce Fields ---

[PATCH 4/4] nfsd: implement the NFSv4.2 CLONE operation

This is basically a remote version of the btrfs CLONE operation, so the implementation is fairly trivial. Made even more trivial by stealing the XDR code and general framework Anna Schumaker's COPY prototype. Signed-off-by: Christoph Hellwig Acked-by: J. Bruce Fields

[PATCH 2/4] vfs: pull btrfs clone API to vfs layer

The btrfs clone ioctls are now adopted by other file systems, with NFS and CIFS already having support for them, and XFS being under active development. To avoid growth of various slightly incompatible implementations, add one to the VFS. Note that clones are different from file copies in

Re: compression disk space saving - what are your results?

>> On a side note, I really wish BTRFS would just add LZ4 support. It's a >> lot more deterministic WRT decompression time than LZO, gets a similar >> compression ratio, and runs faster on most processors for both >> compression and decompression. Relative ratios according to

[PATCH 1/4] locks: new locks_mandatory_area calling convention

Pass a loff_t end for the last byte instead of the 32-bit count parameter to allow full file clones even on 32-bit architectures. While we're at it also drop the pointless inode argument and simplify the read/write selection. Signed-off-by: Christoph Hellwig Acked-by: J. Bruce

move btrfs clone ioctls to common code V2

This patch set moves the existing btrfs clone ioctls that other file system have started to implement to common code, and allows the NFS server to export this functionality to remote systems. This work is based originally on my NFS CLONE prototype, which reused code from Anna Schumaker's NFS COPY

Re: vfs: move btrfs clone ioctls to common code

On Wed, Dec 02, 2015 at 11:40:13AM -0600, Steve French wrote: > If the copy_file_range is allowed to use any offload mechanism then > cifs.ko could be changed as follows, to fallback among the three > possible mechanisms depending on what the target supports. How reliable are the fallbacks? E.g.

[PATCH] fstests: Fix generic/102 fail for btrfs

From: Zhao Lei generic/102 sometimes fails in newest btrfs toolchain, because it use non-mixed mode in default, which request more space for metadata, and no space for data writing. This patch force mixed mode for btrfs in generic/102. Signed-off-by: Zhao Lei

[RFC PATCH] btrfs: flush_space: treat return value of do_chunk_alloc properly

do_chunk_alloc returns 1 when it succeeds to allocate a new chunk. But flush_space will not convert this to 0, and will also return 1. As a result, reserve_metadata_bytes will think that flush_space failed, and may potentially return this value "1" to the caller (depends how reserve_metadata_bytes

[PULL][PATCH 00/12] Minor cleanups and code simplifications

A random set of changes that popped up during code reading. Separated for easier review. For 4.5, please pull. The following changes since commit 1ec218373b8ebda821aec00bb156a9c94fad9cd4: Linux 4.4-rc2 (2015-11-22 16:45:59 -0800)

[PATCH 01/12] btrfs: make btrfs_close_one_device static

Signed-off-by: David Sterba --- fs/btrfs/volumes.c | 3 ++- fs/btrfs/volumes.h | 1 - 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index a6df8fdc1312..e335938825e1 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c

[PATCH 03/12] btrfs: remove wait from struct btrfs_delalloc_work

The value is 0 and never changes, we can propagate the value, remove wait and the implied dead code. Signed-off-by: David Sterba --- fs/btrfs/ctree.h | 1 - fs/btrfs/inode.c | 11 +++ 2 files changed, 3 insertions(+), 9 deletions(-) diff --git a/fs/btrfs/ctree.h

[PATCH 04/12] btrfs: change how delay_iput is tracked in btrfs_delalloc_work

The dellaloc work is not frequently used, the delayed status is once set and read so it looks quite safe to drop the member and store the status in the lowest bit of the inode pointer. Combined with the removal of 'wait' we got +2 objects per 4k slab. Signed-off-by: David Sterba

[PATCH 05/12] btrfs: remove a trivial helper btrfs_set_buffer_uptodate

Signed-off-by: David Sterba --- fs/btrfs/disk-io.c | 5 - fs/btrfs/disk-io.h | 1 - fs/btrfs/extent-tree.c | 2 +- fs/btrfs/volumes.c | 4 ++-- 4 files changed, 3 insertions(+), 9 deletions(-) diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index

[PATCH 08/12] btrfs: make extent_clear_unlock_delalloc return void

Does not return any errors, nor anything from the callgraph. Signed-off-by: David Sterba --- fs/btrfs/extent_io.c | 5 ++--- fs/btrfs/extent_io.h | 2 +- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index

[PATCH 02/12] btrfs: sink parameter wait to btrfs_alloc_delalloc_work

There's only one caller and single value, we can propagate it down to the callee and remove the unused parameter. Signed-off-by: David Sterba --- fs/btrfs/ctree.h | 2 +- fs/btrfs/inode.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git

[PATCH 09/12] btrfs: make end_extent_writepage return void

Does not return any errors, nor anything from the callgraph. The branch in end_bio_extent_writepage has been skipped since 5fd02043553b ("Btrfs: finish ordered extents in their own thread"). Signed-off-by: David Sterba --- fs/btrfs/extent_io.c | 7 ++-

[PATCH 10/12] btrfs: make extent_range_clear_dirty_for_io return void

Does not return any errors, nor anything from the callgraph. There's a BUG_ON but it's a sanity check and not an error condition we could recover from. Signed-off-by: David Sterba --- fs/btrfs/extent_io.c | 3 +-- fs/btrfs/extent_io.h | 2 +- 2 files changed, 2 insertions(+),

[PATCH 07/12] btrfs: make clear_extent_buffer_uptodate return void

Does not return any errors, nor anything from the callgraph. Signed-off-by: David Sterba --- fs/btrfs/extent_io.c | 3 +-- fs/btrfs/extent_io.h | 2 +- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index

[PATCH 11/12] btrfs: make extent_range_redirty_for_io return void

Does not return any errors, nor anything from the callgraph. There's a BUG_ON but it's a sanity check and not an error condition we could recover from. Signed-off-by: David Sterba --- fs/btrfs/extent_io.c | 3 +-- fs/btrfs/extent_io.h | 2 +- 2 files changed, 2 insertions(+),

[PATCH 12/12] btrfs: make set_range_writeback return void

Does not return any errors, nor anything from the callgraph. There's a BUG_ON but it's a sanity check and not an error condition we could recover from. Signed-off-by: David Sterba --- fs/btrfs/extent_io.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

[PATCH 06/12] btrfs: make set_extent_buffer_uptodate return void

Does not return any errors, nor anything from the callgraph. Signed-off-by: David Sterba --- fs/btrfs/extent_io.c | 3 +-- fs/btrfs/extent_io.h | 2 +- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index

[PATCH 2/4] btrfs: make clear_extent_bit helpers static inline

The funcions just wrap the clear_extent_bit API and generate function calls. This increases stack consumption and may negatively affect performance due to icache misses. We can simply make the helpers static inline and keep the type checking and API untouched. The code slightly decreases: text

[PATCH 3/4] btrfs: drop unused parameter from lock_extent_bits

We've always passed 0. Stack usage will slightly decrease. Signed-off-by: David Sterba --- fs/btrfs/disk-io.c | 2 +- fs/btrfs/extent_io.c| 12 ++-- fs/btrfs/extent_io.h| 2 +- fs/btrfs/file.c | 8

[PULL][PATCH 0/4] A few cleanups around extent bit setting helpers

The extent helpers conveniently wrap __set_extent_bit but needlessly do an extra call. We can get rid of it by making them static inline. Series separated by the common underlying set/clear bit function. Aiming for 4.5, please pull.

[PATCH 1/4] btrfs: make set_extent_bit helpers static inline

The funcions just wrap the set_extent_bit API and generate function calls. This increases stack consumption and may negatively affect performance due to icache misses. We can simply make the helpers static inline and keep the type checking and API untouched. The code slightly increases: text

[PATCH 4/4] btrfs: make lock_extent static inline

One call less reduces stack usage, code slightly reduced as well. Signed-off-by: David Sterba --- fs/btrfs/extent_io.c | 5 - fs/btrfs/extent_io.h | 7 ++- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index

Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk

On 25/11/2015 10:05, Laurent Bonnaud wrote: >> > Nice reproducer. >> > Is it 100% reproducible or has a chance to reproduce? > I tried a second time and got a similar kernel backtrace. Hi, any news since you downloaded my FS image ? I kept my corrupted FS in case you wanted more info, but

[PATCH 2/3] btrfs: use GFP_KERNEL for allocations of workqueues

We don't have to use GFP_NOFS to allocate workqueue structures, this is done from mount context or potentially scrub start context, safe to fail in both cases. Signed-off-by: David Sterba --- fs/btrfs/async-thread.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

[PATCH 3/3] btrfs: use GFP_KERNEL for xattr and acl allocations

We don't have to use GFP_NOFS in context of ACL or XATTR actions, not possible to loop through the allocator and it's safe to fail with ENOMEM. Signed-off-by: David Sterba --- fs/btrfs/acl.c | 4 ++-- fs/btrfs/xattr.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)

[PATCH 1/3] btrfs: use GFP_KERNEL for allocations in ioctl handlers

We don't have to use GFP_NOFS in the ioctl handlers because there's no risk of looping through the allocators back to the filesystem. This patch covers only allocations that are directly in the ioctl handlers. Signed-off-by: David Sterba --- fs/btrfs/ioctl.c | 10 +- 1

[PULL][PATCH 0/3] GFP flags adjustments

Part of the planned memory allocation / error handling updates, a lightweight start. We don't need to use GFP_NOFS everywhere, this flag should protect against looping back to the filesystem in certain allocation contexts. GFP_KERNEL is safe in functions started eg. from userspace (like the

Re: vfs: move btrfs clone ioctls to common code

On Thu, Dec 3, 2015 at 4:30 AM, Christoph Hellwig wrote: > On Wed, Dec 02, 2015 at 11:40:13AM -0600, Steve French wrote: >> If the copy_file_range is allowed to use any offload mechanism then >> cifs.ko could be changed as follows, to fallback among the three >> possible mechanisms

Very various speed of grep operation on btrfs partition

Today on work I needed searching some strings in repository. Only machine with windows was available. I am was using grep from Cygwin for this task and I am was surprised about speed of NTFS partition.I decided to repeat this task on my home Linux workstation. [mikhail@localhost ~]$ time grep -rn

Re: btrfs crashing the kernel with Seagate 8TB SMR drives.

On Thu, Dec 03, 2015 at 06:07:52PM +, Codebird wrote: > I've got a nice bug for you - because I can offer you what everyone likes to > see, a precise error message. > > I've got a btrfs filesystem spread over six devices, RAID1 mode. Four of > these are Seagate 8TB archive drives - those SMR

Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk

Laurent Bonnaud wrote on 2015/12/03 18:13 +0100: On 25/11/2015 10:05, Laurent Bonnaud wrote: Nice reproducer. Is it 100% reproducible or has a chance to reproduce? I tried a second time and got a similar kernel backtrace. Hi, any news since you downloaded my FS image ? I kept my

[PATCH] Btrfs: disable online scrub repair on ro cases

This disables repair process on ro cases as it can cause system to be unresponsive on the ASSERT() in repair_io_failure(). This can happen when scrub is running and a hardware error pops up, we should fallback to ro mounts gracefully instead of being unresponsive. Reported-by: Codebird

Re: BUG: failure at fs/btrfs/ctree.h:337/btrfs_chunk_item_size()!

On Mon, Nov 30, 2015 at 11:05:20PM +0100, Vegard Nossum wrote: > With your patch and a new image, I run into a second issue (which is > probably unrelated): Yes, it's unrelated. As pointed out by Qu, the alignment is wrong and more strict checks should catch it. > Should I start a new thread?

Re: [RFC PATCH] btrfs: flush_space: treat return value of do_chunk_alloc properly

On Thu, Dec 03, 2015 at 06:51:03PM +0200, Alex Lyakas wrote: > do_chunk_alloc returns 1 when it succeeds to allocate a new chunk. > But flush_space will not convert this to 0, and will also return 1. > As a result, reserve_metadata_bytes will think that flush_space failed, > and may potentially

Re: BUG: failure at fs/btrfs/ctree.h:337/btrfs_chunk_item_size()!

On Tue, Dec 01, 2015 at 08:50:57AM +0800, Qu Wenruo wrote: > Btrfsck already gives quite good clue on the problem: > > ERROR: chunk_root block unaligned: 4294967168 > ERROR: chunk_root block unaligned: 4294967168 > > Chunk root in superblock is not aligned, and the superblock is not valid. > >

Re: [RFC PATCH] btrfs: flush_space: treat return value of do_chunk_alloc properly

On 12/03/2015 11:51 AM, Alex Lyakas wrote: do_chunk_alloc returns 1 when it succeeds to allocate a new chunk. But flush_space will not convert this to 0, and will also return 1. As a result, reserve_metadata_bytes will think that flush_space failed, and may potentially return this value "1" to

Re: btrfs crashing the kernel with Seagate 8TB SMR drives.

Any chances that this is: https://bugzilla.kernel.org/show_bug.cgi?id=93581 Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature

btrfs crashing the kernel with Seagate 8TB SMR drives.

I've got a nice bug for you - because I can offer you what everyone likes to see, a precise error message. I've got a btrfs filesystem spread over six devices, RAID1 mode. Four of these are Seagate 8TB archive drives - those SMR ones that a few others have reported failing when used with

Re: BUG: failure at fs/btrfs/ctree.h:337/btrfs_chunk_item_size()!

David Sterba wrote on 2015/12/03 18:47 +0100: On Tue, Dec 01, 2015 at 08:50:57AM +0800, Qu Wenruo wrote: Btrfsck already gives quite good clue on the problem: ERROR: chunk_root block unaligned: 4294967168 ERROR: chunk_root block unaligned: 4294967168 Chunk root in superblock is not aligned,

Re: [PATCH v2 0/5] Make btrfs-progs really compatible with any kernel version

On Mon, Nov 23, 2015 at 06:56:09PM +0100, David Sterba wrote: > On Mon, Nov 23, 2015 at 08:56:13PM +0800, Anand Jain wrote: > > Btrfs-progs is a tool for the btrfs kernel and we hope latest btrfs-progs > > be compatible w any set of older/newer kernels. > > > > So far mkfs.btrfs and btrfs-convert

Re: [PATCH v2 0/5] Make btrfs-progs really compatible with any kernel version

Liu Bo wrote on 2015/12/03 17:44 -0800: On Mon, Nov 23, 2015 at 06:56:09PM +0100, David Sterba wrote: On Mon, Nov 23, 2015 at 08:56:13PM +0800, Anand Jain wrote: Btrfs-progs is a tool for the btrfs kernel and we hope latest btrfs-progs be compatible w any set of older/newer kernels. So far

Re: [PATCH 04/12] btrfs: change how delay_iput is tracked in btrfs_delalloc_work

On Thu, Dec 03, 2015 at 05:56:32PM +0100, David Sterba wrote: > The dellaloc work is not frequently used, the delayed status is once set > and read so it looks quite safe to drop the member and store the status > in the lowest bit of the inode pointer. > > Combined with the removal of 'wait' we

Re: [PATCH v2 0/5] Make btrfs-progs really compatible with any kernel version

On Fri, Dec 04, 2015 at 10:08:35AM +0800, Qu Wenruo wrote: > > > Liu Bo wrote on 2015/12/03 17:44 -0800: > >On Mon, Nov 23, 2015 at 06:56:09PM +0100, David Sterba wrote: > >>On Mon, Nov 23, 2015 at 08:56:13PM +0800, Anand Jain wrote: > >>>Btrfs-progs is a tool for the btrfs kernel and we hope

[PATCH] btrfs: only free root_path if it was allocated from the heap

Noticed this while doing some snapshots in a chroot environment btrfs receive can set root_path to either realmnt, which is passed in from the command line, or to a heap allocated via find_mount_root in do_receive. We should only free the later, not the former, as the former results in an