Re: [PATCH] btrfs: Handle delalloc error correctly to avoid deadlock

Please ignore this patch. This patch doesn't handle outstanding_extents well. Thanks, Qu At 02/21/2017 10:29 AM, Qu Wenruo wrote: If run btrfs/125 with nospace_cache or space_cache=v2 mount option, btrfs will block with the following backtrace: Call Trace: __schedule+0x2d4/0xae0

[PATCH] btrfs: Handle delalloc error correctly to avoid deadlock

If run btrfs/125 with nospace_cache or space_cache=v2 mount option, btrfs will block with the following backtrace: Call Trace: __schedule+0x2d4/0xae0 schedule+0x3d/0x90 btrfs_start_ordered_extent+0x160/0x200 [btrfs] ? wake_atomic_t_function+0x60/0x60 btrfs_run_ordered_extent_work+0x25/0x40

Re: mount troubles after crash

At 02/20/2017 10:13 PM, Patrick Schmid wrote: Hi togehter, during a balance run, the server crash. after the crash i got the attached error messages Kernel: 4.9.11 A known bug when qgroup is enabled. Fixed in v4.10-rcs. Please mount using v4.10 kernels and it will mount without

Re: [PATCH] qgroup: Retry after commit on getting EDQUOT

At 02/20/2017 08:51 PM, Goldwyn Rodrigues wrote: On 02/19/2017 11:35 PM, Qu Wenruo wrote: At 02/20/2017 12:35 PM, Goldwyn Rodrigues wrote: Hi Qu, On 02/19/2017 09:07 PM, Qu Wenruo wrote: At 02/19/2017 09:30 PM, Goldwyn Rodrigues wrote: From: Goldwyn Rodrigues We

Re: [PATCH] btrfs: Handle btrfs_reloc_clone_csums error correctly to avoid deadlock

At 02/20/2017 09:43 PM, Filipe Manana wrote: On Mon, Feb 20, 2017 at 12:31 AM, Qu Wenruo wrote: At 02/17/2017 11:25 PM, Filipe Manana wrote: On Fri, Feb 17, 2017 at 12:37 AM, Qu Wenruo wrote: In case of an error the endio handler is

[PATCH 2/4] btrfs: document existence of extent_io ops callbacks

Some of the callbacks defined in btree_extent_io_ops and btrfs_extent_io_ops do always exist so we don't need to check the existence before each call. This patch just reorders the definition and documents which are mandatory/optional. Signed-off-by: David Sterba ---

[PATCH 4/4] btrfs: add dummy callback for readpage_io_failed and drop checks

Make extent_io_ops::readpage_io_failed_hook callback mandatory and define a dummy function for btrfs_extent_io_ops. As the failed IO callback is not performance critical, the branch vs extra trade off does not hurt. Signed-off-by: David Sterba --- fs/btrfs/disk-io.c | 2 +-

[PATCH 0/4] Cleanups in extent_io callbacks

Some of the checks for extent_io callbacks can be safely dropped as they're always defined, plus some dummy callback additions so more checks can be dropped. There's more potential for the same cleanup in other callbacks but this would need more evaluation wheather dummy callbacks vs existence

[PATCH 3/4] btrfs: drop checks for mandatory extent_io_ops callbacks

We know that eadpage_end_io_hook, submit_bio_hook and merge_bio_hook are always defined so we can drop the checks before we call them. Signed-off-by: David Sterba --- fs/btrfs/extent_io.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git

[PATCH 1/4] btrfs: let writepage_end_io_hook return void

There's no error path in any of the instances, always return 0. Signed-off-by: David Sterba --- fs/btrfs/extent_io.c | 9 +++-- fs/btrfs/extent_io.h | 2 +- fs/btrfs/inode.c | 6 ++ 3 files changed, 6 insertions(+), 11 deletions(-) diff --git

[PATCH v3] btrfs-progs: RAID5: Inject data stripe corruption and verify scrub fixes it and retains correct parity.

Test script to create file with specific data-stripe layout.Computes stripe locations. Inject corruption into data-stripe and verify scrubbing process fixes corrupted block. It also validates the corresponding parity stripe. Signed-off-by: Lakshmipathi.G ---

[PATCH 2/3] btrfs: handle allocation error in update_dev_stat_item

Signed-off-by: David Sterba --- fs/btrfs/volumes.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index 1fac98728814..64d6665f6eda 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -6954,7 +6954,8 @@

[PATCH 1/3] btrfs: remove BUG_ON from __tree_mod_log_insert

All callers dereference the 'tm' parameter before it gets to this function, the NULL check does not make much sense here. Signed-off-by: David Sterba --- fs/btrfs/ctree.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c index

[PATCH 3/3] btrfs: do proper error handling in btrfs_insert_xattr_item

The space check in btrfs_insert_xattr_item is duplicated in it's caller (do_setxattr) so we won't hit the BUG_ON. Continuing without any check could be disasterous so turn it to a proper error handling. Signed-off-by: David Sterba --- fs/btrfs/dir-item.c | 3 ++- 1 file

[PATCH 0/3] Remove some BUG_ONs

Minor cleanup in the BUG_ONs, where could be either removed or replaced by proper error handling where the call chain is ready for that. For 4.11. David Sterba (3): btrfs: remove BUG_ON from __tree_mod_log_insert btrfs: handle allocation error in update_dev_stat_item btrfs: do

Re: Why is btrfs_run_delayed_refs() run multiple times

On Mon, Feb 20, 2017 at 5:08 PM, Goldwyn Rodrigues wrote: > Hi, > > Why do we call btrfs_run_delayed_refs multiple times in a function? Some > of the examples are: > > btrfs_commit_transaction() > commit_cowonly_roots() > > Is it because one call can generate more delayed refs

Re: [PATCH 0/5] block subsystem refcounter conversions

On Mon, 2017-02-20 at 17:56 +0100, Peter Zijlstra wrote: > On Mon, Feb 20, 2017 at 07:41:01AM -0800, James Bottomley wrote: > > On Mon, 2017-02-20 at 08:15 -0700, Jens Axboe wrote: > > > On 02/20/2017 04:16 AM, Elena Reshetova wrote: > > > > Now when new refcount_t type and API are finally merged

Why is btrfs_run_delayed_refs() run multiple times

Hi, Why do we call btrfs_run_delayed_refs multiple times in a function? Some of the examples are: btrfs_commit_transaction() commit_cowonly_roots() Is it because one call can generate more delayed refs and hence we need to run them again? Under what scenarios is this possible? -- Goldwyn --

Re: [PATCH 0/5] block subsystem refcounter conversions

On Mon, Feb 20, 2017 at 07:41:01AM -0800, James Bottomley wrote: > On Mon, 2017-02-20 at 08:15 -0700, Jens Axboe wrote: > > On 02/20/2017 04:16 AM, Elena Reshetova wrote: > > > Now when new refcount_t type and API are finally merged > > > (see include/linux/refcount.h), the following > > > patches

Re: [PATCH 0/5] block subsystem refcounter conversions

On 02/20/2017 08:41 AM, James Bottomley wrote: > On Mon, 2017-02-20 at 08:15 -0700, Jens Axboe wrote: >> On 02/20/2017 04:16 AM, Elena Reshetova wrote: >>> Now when new refcount_t type and API are finally merged >>> (see include/linux/refcount.h), the following >>> patches convert various

Re: [PATCH 0/5] block subsystem refcounter conversions

On Mon, 2017-02-20 at 08:15 -0700, Jens Axboe wrote: > On 02/20/2017 04:16 AM, Elena Reshetova wrote: > > Now when new refcount_t type and API are finally merged > > (see include/linux/refcount.h), the following > > patches convert various refcounters in the block susystem from > > atomic_t to

Re: [PATCH 0/5] block subsystem refcounter conversions

On 02/20/2017 04:16 AM, Elena Reshetova wrote: > Now when new refcount_t type and API are finally merged > (see include/linux/refcount.h), the following > patches convert various refcounters in the block susystem from atomic_t > to refcount_t. By doing this we prevent intentional or accidental >

Re: [PATCH] generic/311: Disable dmesg check

Hi Chandan, On 07/17/15 12:56, Chandan Rajendra wrote: When running generic/311 on Btrfs' subpagesize-blocksize patchset (on ppc64 with 4k sectorsize and 16k node/leaf size) I noticed the following call trace, BTRFS (device dm-0): parent transid verify failed on 29720576 wanted 160 found 158

mount troubles after crash

Hi togehter, during a balance run, the server crash. after the crash i got the attached error messages Kernel: 4.9.11 Btrfs-Tools: v4.9.1 btrfs check --repair failed with: couldn't open RDWR because of unsupported option features (3). Open ctree failed is there a way to fix this 140TB

Re: Large no.of extents for a single small file with a fresh RAID5 setup

On Mon, Feb 20, 2017 at 03:53:15PM +0800, Qu Wenruo wrote: > > > At 02/18/2017 10:07 AM, Lakshmipathi.G wrote: > >Hi, > > > >With RAID5, using 3 loop-back devices each has 4GB. On a fresh setup, > >created a 2mb file. > >While checking no.of extents,it shows like: > > > ># ./btrfs-debugfs -f

Re: [PATCH] Btrfs: remove unnecessary constraint when splitting a leaf

On Sat, Feb 18, 2017 at 12:34 AM, Liu Bo wrote: > On Fri, Feb 17, 2017 at 07:16:04PM +, fdman...@kernel.org wrote: >> From: Filipe Manana >> >> If we want to append an item to a leaf we were trying to move off from the >> leaf into its neighbors an

[PATCH] Btrfs: try harder to migrate items to left sibling before splitting a leaf

From: Filipe Manana Before attempting to split a leaf we try to migrate items from the leaf to its right and left siblings. We start by trying to move items into the rigth sibling and, if the new item is meant to be inserted at the end of our leaf, we try to free from our leaf

Re: [PATCH] btrfs: Handle btrfs_reloc_clone_csums error correctly to avoid deadlock

On Mon, Feb 20, 2017 at 12:31 AM, Qu Wenruo wrote: > > > At 02/17/2017 11:25 PM, Filipe Manana wrote: >> >> On Fri, Feb 17, 2017 at 12:37 AM, Qu Wenruo >> wrote: >>> >>> >>> >>> At 02/16/2017 06:03 PM, Filipe Manana wrote: On Thu,

Re: [PATCH] qgroup: Retry after commit on getting EDQUOT

On 02/19/2017 11:35 PM, Qu Wenruo wrote: > > > At 02/20/2017 12:35 PM, Goldwyn Rodrigues wrote: >> Hi Qu, >> >> On 02/19/2017 09:07 PM, Qu Wenruo wrote: >>> >>> >>> At 02/19/2017 09:30 PM, Goldwyn Rodrigues wrote: From: Goldwyn Rodrigues We are facing the

[PATCH 0/5] block subsystem refcounter conversions

Now when new refcount_t type and API are finally merged (see include/linux/refcount.h), the following patches convert various refcounters in the block susystem from atomic_t to refcount_t. By doing this we prevent intentional or accidental underflows or overflows that can led to use-after-free

[PATCH 1/5] block: convert bio.__bi_cnt from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 2/5] block: convert blk_queue_tag.refcnt from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 4/5] block: convert io_context.active_ref from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 3/5] block: convert blkcg_gq.refcnt from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

[PATCH 5/5] block: convert bsg_device.ref_count from atomic_t to refcount_t

refcount_t type and corresponding API should be used instead of atomic_t when the variable is used as a reference counter. This allows to avoid accidental refcounter overflows that might lead to use-after-free situations. Signed-off-by: Elena Reshetova Signed-off-by:

Re: [PATCH 3/5] btrfs: export compression buffer limits in a header

At 02/18/2017 02:05 AM, David Sterba wrote: Move the buffer limit definitions out of compress_file_range. Nice one. No longer need to dig the codes to know the 128K limit now. Reviewed-by: Qu Wenruo Thanks, Qu Signed-off-by: David Sterba ---