[PATCH v2] Btrfs: set keep_lock when necessary in btrfs_defrag_leaves

path->keep_lock may force to lock tree root and higher nodes, and make lock contention worse, thus it needs to be avoided as much as possible. In btrfs_degrag_leaves, path->keep_lock is set but @path immediatley gets released, which is not necessary at all. Signed-off-by: Liu Bo

Re: [PATCH] Btrfs: set keep_lock when necessary in btrfs_defrag_leaves

On Thu, Apr 26, 2018 at 4:01 AM, David Sterba wrote: > On Wed, Apr 25, 2018 at 09:40:34AM +0800, Liu Bo wrote: >> path->keep_lock is set but @path immediatley gets released, this sets >> ->keep_lock only when it's necessary. > > Can you please write down more details for context?

Re: [PATCH] Btrfs: set keep_lock when necessary in btrfs_defrag_leaves

On Wed, Apr 25, 2018 at 09:40:34AM +0800, Liu Bo wrote: > path->keep_lock is set but @path immediatley gets released, this sets > ->keep_lock only when it's necessary. Can you please write down more details for context? This mostly repeats what the code does, but not why. Thanks. -- To

Re: status page

Gandalf Corvotempesta posted on Wed, 25 Apr 2018 14:30:42 +0200 as excerpted: > For me, RAID56 is mandatory. Any ETA for a stable RAID56 ? > Is something we should expect this year, next year, next 10 years, > ? It's complicated... is the best short answer to that. Here's my take at a

Re: Btrfs progs release 4.16.1

David Sterba posted on Wed, 25 Apr 2018 13:02:34 +0200 as excerpted: > On Wed, Apr 25, 2018 at 06:31:20AM +, Duncan wrote: >> David Sterba posted on Tue, 24 Apr 2018 13:58:57 +0200 as excerpted: >> >> > btrfs-progs version 4.16.1 have been released. This is a bugfix >> > release. >> > >> >

Re: [PATCH] btrfs: Change bit number of BTRFS_FS_BALANCE_RUNNING

On 25.04.2018 18:18, Anand Jain wrote: > > > On 04/25/2018 09:16 PM, David Sterba wrote: >> On Wed, Apr 25, 2018 at 03:53:29PM +0300, Nikolay Borisov wrote: >>> Commit ddd93ef3b9d6 ("btrfs: track running balance in a simpler way") >>> which introduced this bit assigned it number 17.

Re: [PATCH] btrfs: Change bit number of BTRFS_FS_BALANCE_RUNNING

On 04/25/2018 09:16 PM, David Sterba wrote: On Wed, Apr 25, 2018 at 03:53:29PM +0300, Nikolay Borisov wrote: Commit ddd93ef3b9d6 ("btrfs: track running balance in a simpler way") which introduced this bit assigned it number 17. Unfortunately this bit is already occupied by the

Re: [PATCH 0/3] enhance btrfs_raid_array[]

On 25.04.2018 14:01, Anand Jain wrote: > Cleanup patches as in the individual change log. > > These patches were sent independently as they aren't related as such, > but as I am updating the 1/3 the 2/3 would endup with conflict. So > here I am putting all of them together with the conflict

Re: Inconsistent behavior of fsync in btrfs

On Wed, Apr 25, 2018 at 7:36 AM, Ashlie Martinez wrote: > I don't really know all that much about the btrfs code, but I was > digging around to try and find the cause of this. Given the fact that > inserting a sleep between the fsyncs gives correct behavior, do you > think the

Re: [PATCH] btrfs: Change bit number of BTRFS_FS_BALANCE_RUNNING

On Wed, Apr 25, 2018 at 03:53:29PM +0300, Nikolay Borisov wrote: > Commit ddd93ef3b9d6 ("btrfs: track running balance in a simpler way") > which introduced this bit assigned it number 17. Unfortunately this bit > is already occupied by the BTRFS_FS_NEED_ASYNC_COMMIT bit. This was > causing bit 17

[PATCH] btrfs: Change bit number of BTRFS_FS_BALANCE_RUNNING

Commit ddd93ef3b9d6 ("btrfs: track running balance in a simpler way") which introduced this bit assigned it number 17. Unfortunately this bit is already occupied by the BTRFS_FS_NEED_ASYNC_COMMIT bit. This was causing bit 17 to be cleared while __btrfs_balance was running which resulted in

Re: status page

On Wed, Apr 25, 2018 at 02:30:42PM +0200, Gandalf Corvotempesta wrote: > 2018-04-25 13:39 GMT+02:00 Austin S. Hemmelgarn : > > Define 'stable'. > > Something ready for production use like ext or xfs with no critical > bugs or with easy data loss. > > > If you just want

Re: Inconsistent behavior of fsync in btrfs

I don't really know all that much about the btrfs code, but I was digging around to try and find the cause of this. Given the fact that inserting a sleep between the fsyncs gives correct behavior, do you think the issue could be related to how btrfs determines whether or not to log a change to an

Re: status page

2018-04-25 13:39 GMT+02:00 Austin S. Hemmelgarn : > Define 'stable'. Something ready for production use like ext or xfs with no critical bugs or with easy data loss. > If you just want 'safe for critical data', it's mostly there already > provided that your admins and

Re: Btrfs progs release 4.16.1

On 2018-04-25 07:29, Christoph Anton Mitterer wrote: On Wed, 2018-04-25 at 07:22 -0400, Austin S. Hemmelgarn wrote: While I can understand Duncan's point here, I'm inclined to agree with David Same from my side... and I run a multi-PiB storage site (though not with btrfs). Cosmetically one

Re: status page

On 2018-04-25 07:13, Gandalf Corvotempesta wrote: 2018-04-23 17:16 GMT+02:00 David Sterba : Reviewed and updated for 4.16, there's no change regarding the overall status, though 4.16 has some raid56 fixes. Thank you! Any ETA for a stable RAID56 ? (or, even better, for a

Re: Btrfs progs release 4.16.1

On Wed, 2018-04-25 at 07:22 -0400, Austin S. Hemmelgarn wrote: > While I can understand Duncan's point here, I'm inclined to agree > with > David Same from my side... and I run a multi-PiB storage site (though not with btrfs). Cosmetically one shouldn't do this in a bugfix release, this should

Re: Btrfs progs release 4.16.1

On 2018-04-25 07:02, David Sterba wrote: On Wed, Apr 25, 2018 at 06:31:20AM +, Duncan wrote: David Sterba posted on Tue, 24 Apr 2018 13:58:57 +0200 as excerpted: btrfs-progs version 4.16.1 have been released. This is a bugfix release. Changes: * remove obsolete tools:

Re: status page

2018-04-23 17:16 GMT+02:00 David Sterba : > Reviewed and updated for 4.16, there's no change regarding the overall > status, though 4.16 has some raid56 fixes. Thank you! Any ETA for a stable RAID56 ? (or, even better, for a stable btrfs ready for production use) I've seen many

Re: Btrfs progs release 4.16.1

On Wed, Apr 25, 2018 at 06:31:20AM +, Duncan wrote: > David Sterba posted on Tue, 24 Apr 2018 13:58:57 +0200 as excerpted: > > > btrfs-progs version 4.16.1 have been released. This is a bugfix > > release. > > > > Changes: > > > > * remove obsolete tools: btrfs-debug-tree,

Re: [PATCH v2] btrfs: kill btrfs_raid_type_names[]

On 04/25/2018 05:45 PM, David Sterba wrote: On Wed, Apr 25, 2018 at 05:44:13PM +0800, Anand Jain wrote: Add a new member struct btrfs_raid_attr::raid_name so that btrfs_raid_array[] can maintain the name of the raid type, and so we can kill btrfs_raid_type_names[]. Signed-off-by: Anand Jain

[PATCH 2/3] btrfs: kill btrfs_raid_group[]

Add a new member struct btrfs_raid_attr::bg_flag so that btrfs_raid_array[] can maintain the bit map flag of the raid type, and so we can kill btrfs_raid_group[]. Signed-off-by: Anand Jain --- fs/btrfs/disk-io.c | 2 +- fs/btrfs/extent-tree.c | 2 +-

[PATCH v3 1/3] btrfs: kill btrfs_raid_type_names[]

Add a new member struct btrfs_raid_attr::raid_name so that btrfs_raid_array[] can maintain the name of the raid type, and so we can kill btrfs_raid_type_names[]. Signed-off-by: Anand Jain Reviewed-by: Qu Wenruo Reviewed-by: Nikolay Borisov

[PATCH 3/3] btrfs: kill btrfs_raid_mindev_error[]

Add a new member struct btrfs_raid_attr::mindev_error so that btrfs_raid_array[] can maintain the error code to return if the minimum numnber of devices required condition is not met while trying to delete a device in the given raid. And so we can kill btrfs_raid_mindev_error[]. Signed-off-by:

[PATCH 0/3] enhance btrfs_raid_array[]

Cleanup patches as in the individual change log. These patches were sent independently as they aren't related as such, but as I am updating the 1/3 the 2/3 would endup with conflict. So here I am putting all of them together with the conflict fixed at my end. And as such there is no change in 2/3

[PATCH] btrfs: kill btrfs_raid_mindev_error[]

Add a new member struct btrfs_raid_attr::mindev_error so that btrfs_raid_array[] can maintain the error code to return if the minimum numnber of devices required condition is not met while trying to delete a device in the given raid. And so we can kill btrfs_raid_mindev_error[]. Signed-off-by:

[PATCH] btrfs: kill btrfs_raid_group[]

Add a new member struct btrfs_raid_attr::bg_flag so that btrfs_raid_array[] can maintain the bit map flag of the raid type, and so we can kill btrfs_raid_group[]. Signed-off-by: Anand Jain --- fs/btrfs/disk-io.c | 2 +- fs/btrfs/extent-tree.c | 2 +-

Re: [PATCH v2] btrfs: kill btrfs_raid_type_names[]

On Wed, Apr 25, 2018 at 05:44:13PM +0800, Anand Jain wrote: > Add a new member struct btrfs_raid_attr::raid_name so that > btrfs_raid_array[] can maintain the name of the raid type, > and so we can kill btrfs_raid_type_names[]. > > Signed-off-by: Anand Jain > Reviewed-by:

[PATCH v2] btrfs: kill btrfs_raid_type_names[]

Add a new member struct btrfs_raid_attr::raid_name so that btrfs_raid_array[] can maintain the name of the raid type, and so we can kill btrfs_raid_type_names[]. Signed-off-by: Anand Jain Reviewed-by: Qu Wenruo Reviewed-by: Nikolay Borisov

Re: [PATCH] btrfs: kill btrfs_raid_type_names[]

diff --git a/fs/btrfs/volumes.h b/fs/btrfs/volumes.h index ef220d541d4b..2acd32ce1573 100644 --- a/fs/btrfs/volumes.h +++ b/fs/btrfs/volumes.h @@ -342,6 +342,7 @@ struct btrfs_raid_attr { int tolerated_failures; /* max tolerated fail devs */ int devs_increment; /* ndevs

Re: [PATCH] btrfs: kill btrfs_raid_type_names[]

On Wed, Apr 25, 2018 at 03:26:08PM +0800, Anand Jain wrote: > Add a new member struct btrfs_raid_attr::raid_name so that > btrfs_raid_array[] can maintain the name of the raid type, > and so we can kill btrfs_raid_type_names[]. > > Signed-off-by: Anand Jain Ok, nice. > +

Re: [PATCH V4] Btrfs: enchanse raid1/10 balance heuristic

On 2018/04/25 17:15, Timofey Titovets wrote: > 2018-04-25 10:54 GMT+03:00 Misono Tomohiro : >> On 2018/04/25 9:20, Timofey Titovets wrote: >>> Currently btrfs raid1/10 balancer bаlance requests to mirrors, >>> based on pid % num of mirrors. >>> >>> Make logic

Re: [PATCH V4] Btrfs: enchanse raid1/10 balance heuristic

2018-04-25 10:54 GMT+03:00 Misono Tomohiro : > On 2018/04/25 9:20, Timofey Titovets wrote: >> Currently btrfs raid1/10 balancer bаlance requests to mirrors, >> based on pid % num of mirrors. >> >> Make logic understood: >> - if one of underline devices are non

Re: [PATCH V4] Btrfs: enchanse raid1/10 balance heuristic

On 2018/04/25 9:20, Timofey Titovets wrote: > Currently btrfs raid1/10 balancer bаlance requests to mirrors, > based on pid % num of mirrors. > > Make logic understood: > - if one of underline devices are non rotational > - Queue leght to underline devices > > By default try use pid %

Re: [PATCH] btrfs: kill btrfs_raid_type_names[]

On 2018年04月25日 15:26, Anand Jain wrote: > Add a new member struct btrfs_raid_attr::raid_name so that > btrfs_raid_array[] can maintain the name of the raid type, > and so we can kill btrfs_raid_type_names[]. > > Signed-off-by: Anand Jain Looks much better than the old

Re: [PATCH] btrfs: kill btrfs_raid_type_names[]

On 25.04.2018 10:26, Anand Jain wrote: > Add a new member struct btrfs_raid_attr::raid_name so that > btrfs_raid_array[] can maintain the name of the raid type, > and so we can kill btrfs_raid_type_names[]. > > Signed-off-by: Anand Jain Makes sense: Reviewed-by:

[PATCH] btrfs: kill btrfs_raid_type_names[]

Add a new member struct btrfs_raid_attr::raid_name so that btrfs_raid_array[] can maintain the name of the raid type, and so we can kill btrfs_raid_type_names[]. Signed-off-by: Anand Jain --- fs/btrfs/extent-tree.c | 18 -- fs/btrfs/volumes.c | 15

Re: Btrfs progs release 4.16.1

David Sterba posted on Tue, 24 Apr 2018 13:58:57 +0200 as excerpted: > btrfs-progs version 4.16.1 have been released. This is a bugfix > release. > > Changes: > > * remove obsolete tools: btrfs-debug-tree, btrfs-zero-log, > btrfs-show-super, btrfs-calc-size Cue the admin-side gripes about

Re: [PATCH V2.1] btrfs-progs: do not merge tree block refs have different root_id

On 2018年04月25日 13:19, Su Yue wrote: > For an extent item which contains many tree block backrefs, like > = > In 020-extent-ref-cases/keyed_block_ref.img > > item 10 key (29470720 METADATA_ITEM 0) itemoff 3450 itemsize 222 >