Re: [PATCH 07/10] dax: export functions for use with btrfs

On Thu, Dec 06, 2018 at 05:46:01AM -0600, Goldwyn Rodrigues wrote: > This is not worth with btrfs. With non-page aligned I/O on btrfs, we > need to copy the first/last page of the extents for CoW. We'll need to do the same for XFS with reflink support anyway. So I'd rather handle it in common cod

Re: [PATCH 7/8] btrfs: be more explicit about allowed flush states

On 3.12.18 г. 17:24 ч., Josef Bacik wrote: > For FLUSH_LIMIT flushers (think evict, truncate) we can deadlock when > running delalloc because we may be holding a tree lock. We can also > deadlock with delayed refs rsv's that are running via the committing > mechanism. The only safe operations

Re: [PATCH] btrfs: raid56: data corruption on a device removal

On 12/12/2018 01:25, Dmitriy Gorokh wrote: > I found that RAID5 or RAID6 filesystem might be got corrupted in the > following scenario: > > 1. Create 4 disks RAID6 filesystem > 2. Preallocate 16 10Gb files > 3. Run fio: 'fio --name=testload --directory=./ --size=10G --numjobs=16 > --bs=64k --iod

Re: [PATCH 1/3] btrfs: Remove unused arguments from btrfs_get_extent_fiemap

Looks good, Reviewed-by: Johannes Thumshirn -- Johannes ThumshirnSUSE Labs Filesystems jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG N

Re: [PATCH 3/3] btrfs: Remove redundant assignment

Looks good, Reviewed-by: Johannes Thumshirn -- Johannes ThumshirnSUSE Labs Filesystems jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG N

Re: [PATCH v2 1/8] btrfs: delayed-ref: Introduce better documented delayed ref structures

On 12/12/2018 08:30, Qu Wenruo wrote: > > +enum btrfs_ref_type { > + BTRFS_REF_NOT_SET = 0, Nit: no need to explicitly initialize an enum to 0. -- Johannes ThumshirnSUSE Labs Filesystems jthumsh...@suse.de+49 911 74053 689 SUSE L

Re: [PATCH v2 2/8] btrfs: extent-tree: Open-code process_func in __btrfs_mod_ref

On 12/12/2018 08:30, Qu Wenruo wrote: > The process_func is never a function hook used anywhere else. > Hmm this sounds odd, maybe something like: The process_func function pointer is local to __btrfs_mod_ref() and points to either btrfs_inc_extent_ref() or btrfs_free_extent(). > Open code it t

Re: [PATCH v2 2/8] btrfs: extent-tree: Open-code process_func in __btrfs_mod_ref

On 2018/12/12 下午5:40, Johannes Thumshirn wrote: > On 12/12/2018 08:30, Qu Wenruo wrote: >> The process_func is never a function hook used anywhere else. >> > > Hmm this sounds odd, maybe something like: > > The process_func function pointer is local to __btrfs_mod_ref() and > points to either b

[PATCH v2.1 1/8] btrfs: delayed-ref: Introduce better documented delayed ref structures

Current delayed ref interface has several problems: - Longer and longer parameter lists bytenr num_bytes parent -- so far so good ref_root owner offset -- I don't feel good now - Different interpretation for the same parameter Above @owner for data ref is inode nu

[PATCH v2.1 2/8] btrfs: extent-tree: Open-code process_func in __btrfs_mod_ref

The process_func function pointer is local to __btrfs_mod_ref() and points to either btrfs_inc_extent_ref() or btrfs_free_extent(). Open code it to make later delayed ref refactor easier, so we can refactor btrfs_inc_extent_ref() and btrfs_free_extent() in different patches. Signed-off-by: Qu Wen

Re: [PATCH v3 0/7] btrfs: qgroup: Delay subtree scan to reduce overhead

On Wed, Dec 12, 2018 at 08:39:46AM +0800, Qu Wenruo wrote: > changelog: > v2: > - Rebase to v4.20-rc1. > - Instead commit transaction after each reloc tree merge, delay it until > merge_reloc_roots() finishes. > - This provides a more natural behavior, and reduce the unnecessary > transaction c

Re: [PATCH v2 0/8] btrfs: Refactor delayed ref parameter list

On Wed, Dec 12, 2018 at 03:30:54PM +0800, Qu Wenruo wrote: > This patchset can be fetched from github: > https://github.com/adam900710/linux/tree/refactor_delayed_ref_parameter > > Which is based on previous delayed subtree scan patchset. > (https://github.com/adam900710/linux/tree/qgroup_delayed_

name hash mismatch

Hello If anyone could help with with "name hash mismatch" error at btrfs. full error is "BTRFS critical (device sda5): corrupt leaf: root=2234 block=244700761008 slot 136 ino=2531, name hash mismatch with key, have 0x0026cd84d" so i could not access one file neither to remove it. uname -a

Re: [PATCH v3] btrfs: improve error handling of btrfs_add_link()

On Tue, Dec 11, 2018 at 04:03:15PM +0100, Johannes Thumshirn wrote: > err holds the return value of either btrfs_del_root_ref() or > btrfs_del_inode_ref() but it hasn't been checked since it's > introduction with commit fe66a05a0679 (Btrfs: improve error handling > for btrfs_insert_dir_item callers

Re: name hash mismatch

On 12.12.18 г. 14:44 ч., Олег Власов wrote: > Hello > If anyone could help with with "name hash mismatch" error at btrfs. > full error is > "BTRFS critical (device sda5): corrupt leaf: root=2234 > block=244700761008 slot 136 ino=2531, name hash mismatch with key, > have 0x0026cd84d" > so

Re: [PATCH] Btrfs: use nofs context when initializing security xattrs to avoid deadlock

On Mon, Dec 10, 2018 at 05:53:35PM +, fdman...@kernel.org wrote: > From: Filipe Manana > > When initializing the security xattrs, we are holding a transaction handle > therefore we need to use a GFP_NOFS context in order to avoid a deadlock > with reclaim in case it's triggered. > > Fixes: 3

Re: [PATCH v3 0/7] btrfs: qgroup: Delay subtree scan to reduce overhead

On 2018/12/12 下午8:37, David Sterba wrote: > On Wed, Dec 12, 2018 at 08:39:46AM +0800, Qu Wenruo wrote: >> changelog: >> v2: >> - Rebase to v4.20-rc1. >> - Instead commit transaction after each reloc tree merge, delay it until >> merge_reloc_roots() finishes. >> - This provides a more natural be

Re: [PATCH v3] btrfs: improve error handling of btrfs_add_link()

On 12/12/2018 13:52, David Sterba wrote: > What I wanted is this: > > --- a/fs/btrfs/inode.c > +++ b/fs/btrfs/inode.c > @@ -6360,12 +6360,16 @@ int btrfs_add_link(struct btrfs_trans_handle *trans, > root->root_key.objectid, parent_ino, >

Re: [PATCH v2 0/8] btrfs: Refactor delayed ref parameter list

On 2018/12/12 下午8:42, David Sterba wrote: > On Wed, Dec 12, 2018 at 03:30:54PM +0800, Qu Wenruo wrote: >> This patchset can be fetched from github: >> https://github.com/adam900710/linux/tree/refactor_delayed_ref_parameter >> >> Which is based on previous delayed subtree scan patchset. >> (https:

Re: name hash mismatch

On 2018/12/12 下午9:00, Nikolay Borisov wrote: > > > On 12.12.18 г. 14:44 ч., Олег Власов wrote: >> Hello >> If anyone could help with with "name hash mismatch" error at btrfs. >> full error is >> "BTRFS critical (device sda5): corrupt leaf: root=2234 >> block=244700761008 slot 136 ino=2531, nam

Re: [PATCH v2] Btrfs: send, fix race with transaction commits that create snapshots

On Tue, Dec 11, 2018 at 10:19:45AM +, fdman...@kernel.org wrote: > From: Filipe Manana > > If we create a snapshot of a snapshot currently being used by a send > operation, we can end up with send failing unexpectedly (returning > -ENOENT error to user space for example). The following diagra

Re: [PATCH v3 0/7] btrfs: qgroup: Delay subtree scan to reduce overhead

On Wed, Dec 12, 2018 at 09:20:33PM +0800, Qu Wenruo wrote: > > > On 2018/12/12 下午8:37, David Sterba wrote: > > On Wed, Dec 12, 2018 at 08:39:46AM +0800, Qu Wenruo wrote: > >> changelog: > >> v2: > >> - Rebase to v4.20-rc1. > >> - Instead commit transaction after each reloc tree merge, delay it un

Re: name hash mismatch

On 2018/12/12 下午9:51, Олег Власов wrote: > Could you guide me ? > What should I do after compile latest btrfs-progs? "btrfs check --readonly " and paste the output. Thanks, Qu > > ср, 12 дек. 2018 г., 16:47 Qu Wenruo quwenruo.bt...@gmx.com > : > > > > On

Re: [PATCH v3 0/7] btrfs: qgroup: Delay subtree scan to reduce overhead

On 2018/12/12 下午9:50, David Sterba wrote: > On Wed, Dec 12, 2018 at 09:20:33PM +0800, Qu Wenruo wrote: >> >> >> On 2018/12/12 下午8:37, David Sterba wrote: >>> On Wed, Dec 12, 2018 at 08:39:46AM +0800, Qu Wenruo wrote: changelog: v2: - Rebase to v4.20-rc1. - Instead commit trans

[PATCH v4] btrfs: improve error handling of btrfs_add_link()

err holds the return value of either btrfs_del_root_ref() or btrfs_del_inode_ref() but it hasn't been checked since it's introduction with commit fe66a05a0679 (Btrfs: improve error handling for btrfs_insert_dir_item callers) in 2012. To quote David: "If the error handling in the error handling fa

Re: [PATCH] btrfs: Refactor main loop in extent_readpages

On Thu, Nov 29, 2018 at 06:41:31PM +0200, Nikolay Borisov wrote: > extent_readpages processes all pages in the readlist in batches of 16, > this is implemented by a single for loop but thanks to an if condition > the loop does 2 things based on whether we've filled the batch or not. > Additionally

Re: [PATCH v2] btrfs: balance dirty metadata pages in btrfs_finish_ordered_io

On 28 May 2018, at 1:48, Ethan Lien wrote: It took me a while to trigger, but this actually deadlocks ;) More below. > [Problem description and how we fix it] > We should balance dirty metadata pages at the end of > btrfs_finish_ordered_io, since a small, unmergeable random write can > potentia

Re: [PATCH] btrfs: Refactor main loop in extent_readpages

On 12.12.18 г. 16:40 ч., David Sterba wrote: > On Thu, Nov 29, 2018 at 06:41:31PM +0200, Nikolay Borisov wrote: >> extent_readpages processes all pages in the readlist in batches of 16, >> this is implemented by a single for loop but thanks to an if condition >> the loop does 2 things based on w

Re: [PATCH v2] btrfs: balance dirty metadata pages in btrfs_finish_ordered_io

On 12.12.2018 15:47 Chris Mason wrote: > On 28 May 2018, at 1:48, Ethan Lien wrote: > > It took me a while to trigger, but this actually deadlocks ;) More > below. > >> [Problem description and how we fix it] >> We should balance dirty metadata pages at the end of >> btrfs_finish_ordered_io, sinc

Re: [PATCH v2] btrfs: balance dirty metadata pages in btrfs_finish_ordered_io

On Wed, Dec 12, 2018 at 03:22:40PM +, Martin Raiber wrote: > On 12.12.2018 15:47 Chris Mason wrote: > > On 28 May 2018, at 1:48, Ethan Lien wrote: > > > > It took me a while to trigger, but this actually deadlocks ;) More > > below. > > > >> [Problem description and how we fix it] > >> We sho

Re: [PATCH] btrfs: raid56: data corruption on a device removal

On Wed, Dec 12, 2018 at 12:25:55AM +, Dmitriy Gorokh wrote: > I found that RAID5 or RAID6 filesystem might be got corrupted in the > following scenario: > > 1. Create 4 disks RAID6 filesystem > 2. Preallocate 16 10Gb files > 3. Run fio: 'fio --name=testload --directory=./ --size=10G --numjobs

Re: [PATCH 6/8] btrfs: loop in inode_rsv_refill

On 3.12.18 г. 17:24 ч., Josef Bacik wrote: > With severe fragmentation we can end up with our inode rsv size being > huge during writeout, which would cause us to need to make very large > metadata reservations. However we may not actually need that much once The sentence beginning with "Howev

Re: [PATCH v2] btrfs: balance dirty metadata pages in btrfs_finish_ordered_io

On 12 Dec 2018, at 10:36, David Sterba wrote: > On Wed, Dec 12, 2018 at 03:22:40PM +, Martin Raiber wrote: >> On 12.12.2018 15:47 Chris Mason wrote: >>> On 28 May 2018, at 1:48, Ethan Lien wrote: >>> >>> Eventually, we have every process in the system waiting on >>> balance_dirty_pages(), and

[PATCH 0/4] Btrfs: a few more cleanups and fixes for clone/deduplication

From: Filipe Manana This is a follow up to the recent change that makes btrfs use the generic helper for cloning and deduplication [1]. It contains a mix of cleanups and fixes, which existed before that change. [1] Btrfs: use generic_remap_file_range_prep() for cloning and deduplication Filipe

[PATCH 1/4] Btrfs: move duplicated nodatasum check into common reflink/dedupe helper

From: Filipe Manana Move the check that verifies if both inodes have checksums disabled or both have them enabled, from the clone and deduplication functions into the new common helper btrfs_remap_file_range_prep(). Signed-off-by: Filipe Manana --- fs/btrfs/ioctl.c | 17 +++-- 1 fi

[PATCH 3/4] Btrfs: check if destination root is read-only for deduplication

From: Filipe Manana Checking if the destination root is read-only was being performed only for clone operations. Make deduplication check it as well, as it does not make sense to not do it, even if it is an operation that does not change the file contents (such as defrag for example, which checks

[PATCH 2/4] Btrfs: use cross mount point check for cloning and deduplication

From: Filipe Manana There is no reason why this check was performed for clone operations but not for deduplication operations, after all deduplication is a special case of cloning. So make the check happen for deduplication as well. This check used to be done and got removed by accident in commi

[PATCH 4/4] Btrfs: remove no longer needed range length checks for deduplication

From: Filipe Manana Comparing the content of the pages in the range to deduplicate is now done by the generic helper generic_remap_file_range_prep(), which takes care of ensuring we do not compare/deduplicate undefined data beyond a file's eof (range from eof to the next block boundary). So remov

Re: [PATCH v2] Btrfs: use generic_remap_file_range_prep() for cloning and deduplication

On Fri, Dec 07, 2018 at 03:25:38PM +, fdman...@kernel.org wrote: > From: Filipe Manana > > Since cloning and deduplication are no longer Btrfs specific operations, we > now have generic code to handle parameter validation, compare file ranges > used for deduplication, clear capabilities when

Re: Kernel traces

On Wed, Dec 12, 2018 at 12:26 AM Stephen R. van den Berg wrote: > > Chris Murphy wrote: > >Also, what scheduler are you using? And do you get different results > >with a different one (better or worse)? > > I'm using CFQ, and I don't think I ever tried a different one. > But, btrfs should be compa

Re: [PATCH AUTOSEL 4.19 052/123] Btrfs: send, fix infinite loop due to directory rename dependencies

On Thu, Dec 06, 2018 at 06:55:19PM +0100, David Sterba wrote: On Wed, Dec 05, 2018 at 04:34:44AM -0500, Sasha Levin wrote: From: Robbie Ko [ Upstream commit a4390aee72713d9e73f1132bcdeb17d72fbbf974 ] ... Signed-off-by: Robbie Ko Reviewed-by: Filipe Manana [Wrote changelog with example and

Re: [PATCH v3 1/2] btrfs: scrub: fix circular locking dependency warning

On 12/04/2018 07:16 PM, David Sterba wrote: On Fri, Nov 30, 2018 at 01:15:23PM +0800, Anand Jain wrote: @@ -3757,10 +3757,13 @@ static noinline_for_stack int scrub_workers_get(struct btrfs_fs_info *fs_info, static noinline_for_stack void scrub_workers_put(struct btrfs_fs_info *fs_info)

SATA/SAS mixed pool

Is it possible/safe to replace a SATA drive in a btrfs RAID10 pool with an SAS drive?

Re: SATA/SAS mixed pool

I've done it with ZFS and hardraid controllers. I see no reason why btrfs should care. On 2018-12-13 07:31, Nathan Dehnel wrote: Is it possible/safe to replace a SATA drive in a btrfs RAID10 pool with an SAS drive?

[PATCH] btrfs: qgroup: Don't scan leaf if we're modifying reloc tree

Since reloc tree doesn't contribute to qgroup numbers, just skip them. This should catch the final leakage of unnecessary data refs for qgroup. The 4G data 16 snapshots test should explain it pretty well: | delayed subtree | refactor delayed ref | this patch (*) -

Re: SATA/SAS mixed pool

On Wed, Dec 12, 2018 at 09:31:02PM -0600, Nathan Dehnel wrote: > Is it possible/safe to replace a SATA drive in a btrfs RAID10 pool > with an SAS drive? For btrfs, a block device is a block device, it's not "racist". You can freely mix and/or replace. If you want to, say, extend a SD card with NB