On 2019/1/23 下午3:15, Qu Wenruo wrote:
> This patchset can be fetched from github:
> https://github.com/adam900710/linux/tree/qgroup_delayed_subtree
>
> Which is based on v5.0-rc1.
>
> This patch address the heavy load subtree scan, but delaying it until
> we're going to modify the swapped tree
Refactor btrfs_qgroup_trace_subtree_swap() into
qgroup_trace_subtree_swap(), which only needs two extent buffer and some
other bool to control the behavior.
This provides the basis for later delayed subtree scan work.
Signed-off-by: Qu Wenruo
---
fs/btrfs/qgroup.c | 78 +
[BUG]
Btrfs/139 will fail with a pretty high possibility if the testing
machine (VM) only has 2G ram.
Resulting the final write success while it should fail due to EDQUOT,
and the result fs will has quota exceeding the limit by 16K.
The simplified reproducer will be: (needs a 2G ram VM)
mkfs.b
Relocation code will drop btrfs_root::reloc_root as soon as
merge_reloc_root() finishes.
However later qgroup code will need to access btrfs_root::reloc_root
after merge_reloc_root() for delayed subtree rescan.
So alter the timming of resetting btrfs_root:::reloc_root, make it
happens after trans
Before this patch, qgroup code trace the whole subtree of subvolume and
reloc trees unconditionally.
This makes qgroup numbers consistent, but it could cause tons of
unnecessary extent trace, which cause a lot of overhead.
However for subtree swap of balance, since both subtree contains the
same
To allow delayed subtree swap rescan, btrfs needs to record per-root
info about which tree blocks get swapped.
So this patch introduces per-root btrfs_qgroup_swapped_blocks structure,
which records which tree blocks get swapped.
The designed workflow will be:
1) Record the subtree root block get
Since it's replaced by new delayed subtree swap code, remove the
original code.
The cleanup is small since most of its core function is still used by
delayed subtree swap trace.
Signed-off-by: Qu Wenruo
---
fs/btrfs/qgroup.c | 94 ---
fs/btrfs/qgroup.
This patchset can be fetched from github:
https://github.com/adam900710/linux/tree/qgroup_delayed_subtree
Which is based on v5.0-rc1.
This patch address the heavy load subtree scan, but delaying it until
we're going to modify the swapped tree block.
The overall workflow is:
1) Record the subtre
From: Josef Bacik
Qgroups will do the old roots lookup at delayed ref time, which could be
while walking down the extent root while running a delayed ref. This
should be fine, except we specifically lock eb's in the backref walking
code irrespective of path->skip_locking, which deadlocks the sys
On 2019/1/23 上午12:32, David Sterba wrote:
> On Tue, Jan 15, 2019 at 04:16:00PM +0800, Qu Wenruo wrote:
>> And to co-operate this, also delayed btrfs_drop_snapshot() call on reloc
>> tree, btrfs_drop_snapshot() call will also be delayed to
>> clean_dirty_subvs().
>
> Can you please rephrase this
On 2019/1/23 上午12:28, David Sterba wrote:
> On Tue, Jan 15, 2019 at 04:15:57PM +0800, Qu Wenruo wrote:
>> This patchset can be fetched from github:
>> https://github.com/adam900710/linux/tree/qgroup_delayed_subtree
>>
>> Which is based on v5.0-rc1.
>>
>> This patch address the heavy load subtree
On 01/19/2019 02:48 PM, Anand Jain wrote:
Both btrfs_find_device() and find_device() does the same things expect
that latter function is not keen in seed device in the scan-context. So
merge them.
Signed-off-by: Anand Jain
A gentle ping.
Thanks, Anand
---
v2: use bool instead of int.
On 2019/1/23 上午7:41, Matthew Friday wrote:
> Hi all,
>
> I recently started learning BTRFS internals, and one think that I
> cannot find is filesystem debugger to browse on disk data structures
> (like xfs_db or ext debugfs).
You need "btrfs inspect dump-tree" and "btrfs inspect dump-super"
>
Hi all,
I recently started learning BTRFS internals, and one think that I
cannot find is filesystem debugger to browse on disk data structures
(like xfs_db or ext debugfs).
Do BTRFS provide similar way to navigate on disk structures? I can see
the btrfs-debug-tree utility which provide whole tree
On Tue, Jan 22, 2019 at 6:43 PM Chris Murphy wrote:
>
> On Tue, Jan 22, 2019 at 9:41 AM Thiago Ramon wrote:
> >
> > Back again with pretty much the same problem, but now without a
> > reasonable cause:
> > I've bought a couple new 8TB disks, recovered everything I needed from
> > my previously da
On 2019/1/23 上午12:55, David Sterba wrote:
> On Tue, Jan 15, 2019 at 04:16:02PM +0800, Qu Wenruo wrote:
>> +
>> +block = kmalloc(sizeof(*block), GFP_NOFS);
>> +if (!block) {
>> +ret = -ENOMEM;
>
> This goes to 'out' that marks quota as inconsistent, is this
> intentional?
Ye
Signed-off-by: Matthew Friday
---
fs/btrfs/ioctl.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 9c8e1734429c..6243f734c0cd 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -3278,7 +3278,6 @@ static int btrfs_extent_same(struct inode *src,
On 2019/1/23 上午1:47, David Sterba wrote:
> On Fri, Jan 18, 2019 at 10:19:51AM +0800, Qu Wenruo wrote:
>> Patchset can be fetched from github:
>> https://github.com/adam900710/linux/tree/write_time_tree_checker
>> Which is based on v5.0-rc1 tag.
>>
>> This patchset has the following two features:
On Tue, Jan 22, 2019 at 9:41 AM Thiago Ramon wrote:
>
> Back again with pretty much the same problem, but now without a
> reasonable cause:
> I've bought a couple new 8TB disks, recovered everything I needed from
> my previously damaged FS to a new BTRFS on those 2 drives (single copy
> mode), dou
On Tue, Jan 22, 2019 at 12:37:34PM -0700, Chris Murphy wrote:
> On Tue, Jan 22, 2019 at 10:57 AM Andrei Borzenkov wrote:
> > "Related" is in the eye of the beholder. Clone subvolume, delete content
> > of clone, reflink content of another volume into clone. Are original
> > subvolume and clone rel
On Tue, Jan 22, 2019 at 10:57 AM Andrei Borzenkov wrote:
>
> 22.01.2019 9:28, Chris Murphy пишет:
> > On Mon, Jan 21, 2019 at 11:00 PM Remi Gauvin wrote:
> >>
> >> On 2019-01-21 11:54 p.m., Chris Murphy wrote:
> >> #
> >>>
> >>> I expect the last command to fail because 1.ro1 is not the parent of
22.01.2019 9:28, Chris Murphy пишет:
> On Mon, Jan 21, 2019 at 11:00 PM Remi Gauvin wrote:
>>
>> On 2019-01-21 11:54 p.m., Chris Murphy wrote:
>> #
>>>
>>> I expect the last command to fail because 1.ro1 is not the parent of
>>> 2.ro2. The command completes, and 2.ro2 is on the destination, and at
On Fri, Jan 18, 2019 at 10:19:51AM +0800, Qu Wenruo wrote:
> Patchset can be fetched from github:
> https://github.com/adam900710/linux/tree/write_time_tree_checker
> Which is based on v5.0-rc1 tag.
>
> This patchset has the following two features:
> - Tree block validation output enhancement
>
On Fri, Jan 18, 2019 at 10:19:54AM +0800, Qu Wenruo wrote:
> This BUG_ON() is really just a crappy way to workaround the _must_check
> attribute of submit_one_bio().
>
> Now kill the BUG_ON() and allow flush_write_bio() to return error
> number.
>
> Also add _must_check attribute to flush_write_b
On Tue, Jan 22, 2019 at 5:20 PM Eli V wrote:
>
> On Tue, Jan 22, 2019 at 11:03 AM Eli V wrote:
> >
> > On Tue, Jan 22, 2019 at 10:42 AM Filipe Manana wrote:
> > >
> > > On Tue, Jan 22, 2019 at 3:26 PM Eli V wrote:
> > > >
> > > > I seem to have it a deadlock trying out btrfs send & receive. Now
On Tue, Jan 22, 2019 at 11:03 AM Eli V wrote:
>
> On Tue, Jan 22, 2019 at 10:42 AM Filipe Manana wrote:
> >
> > On Tue, Jan 22, 2019 at 3:26 PM Eli V wrote:
> > >
> > > I seem to have it a deadlock trying out btrfs send & receive. Now I
> > > haven't used btrfs send & receive much, so don't have
On Tue, Jan 15, 2019 at 04:16:03PM +0800, Qu Wenruo wrote:
> +int btrfs_qgroup_trace_subtree_after_cow(struct btrfs_trans_handle *trans,
> + struct btrfs_root *root,
> + struct extent_buffer *subv_eb)
> +{
> + struct btrf
On Tue, Jan 15, 2019 at 04:16:02PM +0800, Qu Wenruo wrote:
> +/*
> + * Record swapped tree blocks of a file/subvolume tree for delayed subtree
> + * trace code. For detail check comment in fs/btrfs/qgroup.c.
> + */
> +struct btrfs_qgroup_swapped_blocks {
> + spinlock_t lock;
> + struct rb_r
Back again with pretty much the same problem, but now without a
reasonable cause:
I've bought a couple new 8TB disks, recovered everything I needed from
my previously damaged FS to a new BTRFS on those 2 drives (single copy
mode), double-checked if everything was fine, then wipefs'd the old
disks a
On Tue, Jan 15, 2019 at 04:16:01PM +0800, Qu Wenruo wrote:
> Refactor btrfs_qgroup_trace_subtree_swap() into
> qgroup_trace_subtree_swap(), which only needs two extent buffer and some
> other bool to control the behavior.
>
> This provides the basis for later delayed subtree scan work.
>
> Signed
On Tue, Jan 15, 2019 at 04:16:00PM +0800, Qu Wenruo wrote:
> And to co-operate this, also delayed btrfs_drop_snapshot() call on reloc
> tree, btrfs_drop_snapshot() call will also be delayed to
> clean_dirty_subvs().
Can you please rephrase this paragraph?
> This patch will increase the size of bt
On Tue, Jan 15, 2019 at 04:15:57PM +0800, Qu Wenruo wrote:
> This patchset can be fetched from github:
> https://github.com/adam900710/linux/tree/qgroup_delayed_subtree
>
> Which is based on v5.0-rc1.
>
> This patch address the heavy load subtree scan, but delaying it until
> we're going to modif
On Tue, Jan 22, 2019 at 10:42 AM Filipe Manana wrote:
>
> On Tue, Jan 22, 2019 at 3:26 PM Eli V wrote:
> >
> > I seem to have it a deadlock trying out btrfs send & receive. Now I
> > haven't used btrfs send & receive much, so don't have much experience
> > with them. Anyways, bug report and stack
On Tue, Jan 22, 2019 at 3:26 PM Eli V wrote:
>
> I seem to have it a deadlock trying out btrfs send & receive. Now I
> haven't used btrfs send & receive much, so don't have much experience
> with them. Anyways, bug report and stack traces:
> https://bugzilla.kernel.org/show_bug.cgi?id=202383
This
I seem to have it a deadlock trying out btrfs send & receive. Now I
haven't used btrfs send & receive much, so don't have much experience
with them. Anyways, bug report and stack traces:
https://bugzilla.kernel.org/show_bug.cgi?id=202383
Seems like the receive is hung as well as several kworkers.
Tried to run metadata-only balance a btrfs filesystem with RAID-10
metadata to RAID-1 metadata, it failed with "No space left on device".
Seriously, 20 TB of free disk space is not enough to convert some 25 GB
of metadata to a different format? O_o
Kernel is 4.18.20.
# time btrfs balance star
On 2019-01-22 13:43, Anand Jain wrote:
On 01/21/2019 07:56 PM, Steven Davies wrote:
On 2018-05-16 11:03, Anand Jain wrote:
+ break;
+ }
I noticed that it's possible to pass this option multiple times at
mount, which sets multiple devices as read mirrors. While tha
On 01/21/2019 07:56 PM, Steven Davies wrote:
On 2018-05-16 11:03, Anand Jain wrote:
Going back to an old patchset I was testing this weekend:
Adds the mount option:
mount -o read_mirror_policy=
To set the devid of the device which should be used for read. That
means all the normal reads
[re-posting old message, it seems it was not correctly posted due to
subscription issue]
Hello
I am running Ubuntu Server 16.04 LTS with HWE stack (4.18 kernel).
System is running on 2 protected SSDs in RAID1 mode, separate SSD
assigned for swap and media download / processing cache and main data
Hi Filipe,
Thank you for your response. I realize it was a long time, ago, but we
are just now in the process of moving to stable kernel 4.14.x.
Regarding the fix, I see now the relevant code in "btrfs_remove_block_group":
mutex_lock(&fs_info->chunk_mutex);
if (!list_empty(&em->list)) {
40 matches
Mail list logo
