On 26.04.2018 09:24, Qu Wenruo wrote:
> fs_info can be extracted from btrfs_block_group_cache, and all
> btrfs_block_group_cache is created by btrfs_create_block_group_cache()
> with fs_info initialized, no need to worry about NULL pointer
> dereference.
>
> Signed-off-by: Qu Wenruo
I very mu
fs_info can be extracted from btrfs_block_group_cache, and all
btrfs_block_group_cache is created by btrfs_create_block_group_cache()
with fs_info initialized, no need to worry about NULL pointer
dereference.
Signed-off-by: Qu Wenruo
---
fs/btrfs/extent-tree.c | 8
include/trace/
On 26.04.2018 04:27, Liu Bo wrote:
> 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
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
---
v2: update c
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? This mostly repea
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 unsubscribe
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 some
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.
>> >
>> >
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. Unfortunate
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 BTRFS_FS_NEED_AS
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 fixe
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 issue could be relat
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 t
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 fs_info-
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 'safe for critical data', i
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 i
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 operators are careful. Assu
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 sh
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 stable btrfs
ready for
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
h
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: btrfs-debug-tre
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 improvements in th
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, btrfs-zero-log,
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
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 +-
fs/btrfs/volumes.c | 19 ---
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
---
v2->v3:
use const char raid_name[8]
v1->v2:
add s
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: Ana
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
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: Ana
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 +-
fs/btrfs/volumes.c | 19 ---
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: Qu Wenruo
> Reviewed-by
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
---
v1->v2:
add space after =. Such as..
+
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 ha
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.
> + .raid_name
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 understood:
>>> - if one of underline
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 rotational
>> - Queue leght to under
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 % num_mirro
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: Nikolay Borisov
> ---
> fs/
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 way.
Reviewed-by: Qu Wen
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 +++
fs/btrfs/vo
40 matches
Mail list logo
