do_chunk_alloc implements a loop checking whether there is a pending
chunk allocation and if so causes the caller do loop. Generally this
loop is executed only once, however testing with btrfs/072 on a
single core vm machines uncovered an extreme case where the system
could loop indefinitely. This
On 04/04/2018 02:34 AM, David Sterba wrote:
The function is called once and is fairly small, we can merge it with
the caller.
Signed-off-by: David Sterba
Reviewed-by: Anand Jain
Thanks, Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a messag
On 04/04/2018 02:34 AM, David Sterba wrote:
This is a preparatory cleanup that will make clear that the only
successful way out of btrfs_init_dev_replace_tgtdev will also set the
device_out to a valid pointer. With this guarantee, the callers can be
simplified.
Signed-off-by: David Sterba
R
On 04/04/2018 02:34 AM, David Sterba wrote:
The function logically belongs there and there's only a single caller,
no need to export it. No code changes.
Signed-off-by: David Sterba
Reviewed-by: Anand Jain
Thanks, Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-
On 04/04/2018 02:34 AM, David Sterba wrote:
The function will be used outside of volumes.c, the allocation
btrfs_alloc_device is also exported.
Signed-off-by: David Sterba
Reviewed-by: Anand Jain
Thanks, Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
th
@@ -2716,6 +2718,7 @@ static long btrfs_ioctl_rm_dev(struct file *file, void
__user *arg)
ret = BTRFS_ERROR_DEV_EXCL_RUN_IN_PROGRESS;
goto out_drop_write;
}
+ mutex_lock(&fs_info->volume_mutex);
vol_args = memdup_user(arg, sizeof(*vol_args));
@@ -3926,11 +3925,11 @@ int btrfs_balance(struct btrfs_balance_control *bctl,
return ret;
out:
if (bctl->flags & BTRFS_BALANCE_RESUME)
- __cancel_balance(fs_info);
- else {
+ reset_balance_state(fs_info);
reset_balance_state() is something
Hello,
I have a problem when mounting the btrfs system with two units (one in SEED
mode and the other in read-write mode)
Initially it is functioning correctly in production:
btrfs fi sh
Label: 'SEED_MD2' uuid: 285b16fa-b297-43ed-bb3b-311950729eb6
Total devices 2 FS bytes used 2.00Ti
On 2018年04月05日 19:27, Senén Vidal Blanco wrote:
> Hello,
> I have a problem when mounting the btrfs system with two units (one in SEED
> mode and the other in read-write mode)
>
> Initially it is functioning correctly in production:
>
> btrfs fi sh
> Label: 'SEED_MD2' uuid: 285b16fa-b297-4
On Thu, Apr 05, 2018 at 10:40:15AM +0300, Nikolay Borisov wrote:
> do_chunk_alloc implements a loop checking whether there is a pending
> chunk allocation and if so causes the caller do loop. Generally this
> loop is executed only once, however testing with btrfs/072 on a
> single core vm machines
On Thu, Apr 05, 2018 at 05:42:14PM +0800, Anand Jain wrote:
>
>
> > @@ -3926,11 +3925,11 @@ int btrfs_balance(struct btrfs_balance_control
> > *bctl,
> > return ret;
> > out:
> > if (bctl->flags & BTRFS_BALANCE_RESUME)
> > - __cancel_balance(fs_info);
> > - else {
> > +
On Thu, Apr 05, 2018 at 05:41:57PM +0800, Anand Jain wrote:
>
> > @@ -2716,6 +2718,7 @@ static long btrfs_ioctl_rm_dev(struct file *file,
> > void __user *arg)
> > ret = BTRFS_ERROR_DEV_EXCL_RUN_IN_PROGRESS;
> > goto out_drop_write;
> > }
> > + mutex_lock(&fs_info->v
On Tue, Apr 03, 2018 at 08:34:01PM +0200, David Sterba wrote:
> This series gets rid of the volume mutex. The fstests do not pass
> cleanly, 2 or more tests fail so this needs to be fixed, but otherwise
> majority of the work ready for review.
>
> The merge target is 4.18 and I'll probably not get
On Wed, Mar 28, 2018 at 04:43:02AM +0800, Anand Jain wrote:
> I understand reason behind string should not be split, but I
> thought here will be an exception, as if you want to search
> for the string you will still use "unsupported checksum algorithm"
> which is still in one line.
> Abo
On 5.04.2018 16:55, David Sterba wrote:
> On Thu, Apr 05, 2018 at 10:40:15AM +0300, Nikolay Borisov wrote:
>> do_chunk_alloc implements a loop checking whether there is a pending
>> chunk allocation and if so causes the caller do loop. Generally this
>> loop is executed only once, however testin
On Thu, Apr 05, 2018 at 06:04:12PM +0300, Nikolay Borisov wrote:
>
>
> On 5.04.2018 16:55, David Sterba wrote:
> > On Thu, Apr 05, 2018 at 10:40:15AM +0300, Nikolay Borisov wrote:
> >> do_chunk_alloc implements a loop checking whether there is a pending
> >> chunk allocation and if so causes the
On Sat, Mar 31, 2018 at 06:11:56AM +0800, Liu Bo wrote:
> Currently if some fatal errors occur, like all IO get -EIO, resources
> would be cleaned up when
> a) transaction is being committed or
> b) BTRFS_FS_STATE_ERROR is set
>
> However, in some rare cases, resources may be left alone after tran
Hi.
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 9.9156)
The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126,
v4.15.15: Build OK!
v4.14.32: Build OK!
On Sat, Mar 31, 2018 at 06:11:55AM +0800, Liu Bo wrote:
> This is running in a typical write path, not inside a critical path
> where we have to abort the running transaction, so it's OK to return
> errors to callers and eventually to userspace.
I'm not sure this is entierly correct, several other
On Fri, Mar 30, 2018 at 12:58:47PM +0300, Nikolay Borisov wrote:
> add_pinned_bytes reallyc ares whether the bytes being pinned are either
> data or metadata. To that effect is checks whether the 'owner' argument
> is less than BTRFS_FIRST_FREE_OBJECTID (256). This works because
> owner can really
On Tue, Apr 03, 2018 at 01:59:47AM +0800, Liu Bo wrote:
> 0, 1 and <0 can be returned by btrfs_next_leaf(), and when <0 is
> returned, path->nodes[0] could be NULL, log_dir_items lacks such a
> check for <0 and we may run into a null pointer dereference panic.
>
> Fixes: e02119d5a7b4 ("Btrfs: Add
On Thu, Apr 05, 2018 at 04:42:34PM +, Sasha Levin wrote:
> Hi.
>
> [This is an automated email]
>
> This commit has been processed by the -stable helper bot and determined
> to be a high probability candidate for -stable trees. (score: 9.9156)
>
> The bot has tested the following trees: v4.1
On Tue, Apr 03, 2018 at 01:59:48AM +0800, Liu Bo wrote:
> If errors were returned by btrfs_next_leaf(), replay_dir_deletes needs
> to bail out, otherwise @ret would be forced to be 0 after 'break;' and
> the caller won't be aware of it.
>
> Fixes: e02119d5a7b4 ("Btrfs: Add a write ahead tree log t
On Mon, Apr 02, 2018 at 05:24:11PM +0800, Su Yue wrote:
> The function btrfs_get_block_group_info() was introduced by the
> commit 5af3e8cce8b7 ("Btrfs: make filesystem read-only when submitting
> barrier fails") which used it in disk-io.c.
>
> However, the function is only called in ioctl.c now.
On Wed, Apr 04, 2018 at 03:57:42PM +0300, Nikolay Borisov wrote:
> It's used to print its pointer in a debug statement but doesn't really
> bring any useful information to the error message.
>
> Signed-off-by: Nikolay Borisov
Reviewed-by: David Sterba
--
To unsubscribe from this list: send the
On Thu, Apr 05, 2018 at 07:11:14PM +0200, David Sterba wrote:
>On Thu, Apr 05, 2018 at 04:42:34PM +, Sasha Levin wrote:
>> Hi.
>>
>> [This is an automated email]
>>
>> This commit has been processed by the -stable helper bot and determined
>> to be a high probability candidate for -stable trees
On Thu, Apr 5, 2018 at 9:11 AM, David Sterba wrote:
> On Sat, Mar 31, 2018 at 06:11:56AM +0800, Liu Bo wrote:
>> Currently if some fatal errors occur, like all IO get -EIO, resources
>> would be cleaned up when
>> a) transaction is being committed or
>> b) BTRFS_FS_STATE_ERROR is set
>>
>> However
On Thu, Apr 5, 2018 at 9:48 AM, David Sterba wrote:
> On Sat, Mar 31, 2018 at 06:11:55AM +0800, Liu Bo wrote:
>> This is running in a typical write path, not inside a critical path
>> where we have to abort the running transaction, so it's OK to return
>> errors to callers and eventually to usersp
On Thu, Apr 05, 2018 at 07:11:14PM +0200, David Sterba wrote:
> On Thu, Apr 05, 2018 at 04:42:34PM +, Sasha Levin wrote:
> > Hi.
> >
> > [This is an automated email]
> >
> > This commit has been processed by the -stable helper bot and determined
> > to be a high probability candidate for -sta
On 5.04.2018 20:02, David Sterba wrote:
> On Tue, Apr 03, 2018 at 01:59:47AM +0800, Liu Bo wrote:
>> 0, 1 and <0 can be returned by btrfs_next_leaf(), and when <0 is
>> returned, path->nodes[0] could be NULL, log_dir_items lacks such a
>> check for <0 and we may run into a null pointer dereferen
Although just one patch, it needs the extent buffer cleanup code as
basis, so please fetch it from my github repo:
https://github.com/adam900710/btrfs-progs/tree/dump_tree_multi_blocks
This patch allow -b to be specified multiple times, and add extra basic
check for them.
For later enhancement (Is
Reuse extent-cache facility to record multiple bytenr so '-b|--block'
can be specified multiple times.
Despite that, add a sector size alignment check before we try to print a
tree block.
(Please note that, nodesize alignment check is not suitable here as meta
chunk start bytenr could be unaligned
Reuse extent-cache facility to record multiple bytenr so '-b|--block'
can be specified multiple times.
Despite that, add a sector size alignment check before we try to print a
tree block.
(Please note that, nodesize alignment check is not suitable here as meta
chunk start bytenr could be unaligned
Corrupted extent tree (either the root node or leaf) can normally block
us from open the fs.
As normally open_ctree() has the following call chain:
__open_ctree_fd()
|- btrfs_setup_all_roots()
|- btrfs_read_block_groups()
And we will search block group items in extent tree.
And considerin
34 matches
Mail list logo
