Somehow this ends up with crash in btrfs/124, I'm trying to figure out
what went wrong.
thanks,
liubo
On Tue, Sep 4, 2018 at 6:14 PM, Liu Bo wrote:
> __btrfs_end_transaction() has done the metadata release twice,
> probably because it used to process delayed refs in between, but now
> that we
On 2018/9/5 下午9:11, David Sterba wrote:
> On Wed, Sep 05, 2018 at 01:03:39PM +0800, Qu Wenruo wrote:
>> Tree reloc tree doesn't contribute to qgroup numbers, as we have
>
> I think you can call it just 'reloc tree', I'm fixing that in all
> changelogs and comments anyway.
But there is another
пт, 24 авг. 2018 г. в 7:41, Lakshmipathi.G :
>
> Hi -
>
> dduper is an offline dedupe tool. Instead of reading whole file blocks and
> computing checksum, It works by fetching checksum from BTRFS csum tree. This
> hugely improves the performance.
>
> dduper works like:
> - Read csum for
On Tue, Sep 04, 2018 at 07:55:00PM -0600, Chris Murphy wrote:
> https://rwmj.wordpress.com/2018/09/04/nbdkit-as-a-flexible-alternative-to-loopback-mounts/
>
> This is a pretty cool writeup. I can vouch Btrfs will format mount,
> write to, scrub, and btrfs check works on an 8EiB (virtual) disk.
>
On Wed, Sep 05, 2018 at 01:03:39PM +0800, Qu Wenruo wrote:
> Tree reloc tree doesn't contribute to qgroup numbers, as we have
I think you can call it just 'reloc tree', I'm fixing that in all
changelogs and comments anyway.
> accounted them at balance time (check replace_path()).
>
> Skip such
On Fri, Aug 31, 2018 at 10:29:27AM +0800, Qu Wenruo wrote:
> This patchset can be fetched from github:
> https://github.com/adam900710/linux/tree/qgroup_inherit_check
> Which is based on v4.19-rc1 tag.
>
> This patchset will first set btrfs_qgroup_inherit structure size limit
> from PAGE_SIZE to
On 5.09.2018 09:29, Qu Wenruo wrote:
> btrfs_print_tree() uses depth-first search to print a subtree, it works
> fine until we have 3 level tree.
>
> In that case, leaves and nodes will be printed in a depth-first order,
> making it pretty hard to locate level 1 nodes.
>
> This patch will
On 2018/9/5 8:33 PM, Christoph Anton Mitterer wrote:
On Wed, 2018-09-05 at 15:04 +0800, Su Yue wrote:
Agreed with Qu, btrfs-check shall not try to do any write.
Well.. it could have been just some coincidence :-)
I found the errors should blame to something about inode_extref check
in
On Wed, 2018-09-05 at 15:04 +0800, Su Yue wrote:
> Agreed with Qu, btrfs-check shall not try to do any write.
Well.. it could have been just some coincidence :-)
> I found the errors should blame to something about inode_extref check
> in lowmem mode.
So you mean errors in btrfs-check... and
On 5.09.2018 09:29, Qu Wenruo wrote:
> Introduce a new function, btrfs_next_sibling_tree_block(), which could
> find any sibling tree blocks at path->lowest_level, unlike level 0
> limited btrfs_next_leaf().
>
> Since this function is more generic than btrfs_next_leaf(), also make
>
On 5.09.2018 10:46, Qu Wenruo wrote:
>
>
> On 2018/9/5 下午3:41, Nikolay Borisov wrote:
>>
>>
>> On 5.09.2018 08:53, Qu Wenruo wrote:
>>>
>>>
>>> On 2018/9/5 下午1:42, Nikolay Borisov wrote:
On 5.09.2018 05:10, Qu Wenruo wrote:
>
>
> On 2018/8/16 下午9:10, Nikolay
On 2018/9/5 下午3:41, Nikolay Borisov wrote:
>
>
> On 5.09.2018 08:53, Qu Wenruo wrote:
>>
>>
>> On 2018/9/5 下午1:42, Nikolay Borisov wrote:
>>>
>>>
>>> On 5.09.2018 05:10, Qu Wenruo wrote:
On 2018/8/16 下午9:10, Nikolay Borisov wrote:
> This commit enables the delayed refs
On 5.09.2018 09:29, Qu Wenruo wrote:
> When printing tree nodes, we output slots like:
> key (EXTENT_TREE ROOT_ITEM 0) block 73625600 (17975) gen 16
>
> The number in the parentheses is blockptr / nodesize.
>
> However this number doesn't really do any thing useful.
> And in fact for
On 5.09.2018 09:29, Qu Wenruo wrote:
> As the @root parameter is only used to get @fs_info, use fs_info
> directly instead.
>
> Signed-off-by: Qu Wenruo
Reviewed-by: Nikolay Borisov
> ---
> cmds-restore.c | 4 ++--
> ctree.c| 11 +--
> ctree.h| 4 ++--
> 3 files
On 5.09.2018 08:53, Qu Wenruo wrote:
>
>
> On 2018/9/5 下午1:42, Nikolay Borisov wrote:
>>
>>
>> On 5.09.2018 05:10, Qu Wenruo wrote:
>>>
>>>
>>> On 2018/8/16 下午9:10, Nikolay Borisov wrote:
This commit enables the delayed refs infrastructures. This entails doing
the following:
On 09/04/2018 04:24 AM, Christoph Anton Mitterer wrote:
Hey.
On Fri, 2018-08-31 at 10:33 +0800, Su Yue wrote:
Can you please fetch btrfs-progs from my repo and run lowmem check
in readonly?
Repo: https://github.com/Damenly/btrfs-progs/tree/lowmem_debug
It's based on v4.17.1 plus additonal
Originally this test case was designed to work with only 4K sectorsize.
Now enhance it to work with any sector sizes and makes the following
changes:
Output file not to contain any traces of sector size.
Use max_inline=0 mount option so that it meets the requisite of non inline
regular extent.
btrfs_print_tree() uses depth-first search to print a subtree, it works
fine until we have 3 level tree.
In that case, leaves and nodes will be printed in a depth-first order,
making it pretty hard to locate level 1 nodes.
This patch will use breadth-first search for btrfs_print_tree().
It will
As the @root parameter is only used to get @fs_info, use fs_info
directly instead.
Signed-off-by: Qu Wenruo
---
cmds-restore.c | 4 ++--
ctree.c| 11 +--
ctree.h| 4 ++--
3 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/cmds-restore.c b/cmds-restore.c
Introduce a new function, btrfs_next_sibling_tree_block(), which could
find any sibling tree blocks at path->lowest_level, unlike level 0
limited btrfs_next_leaf().
Since this function is more generic than btrfs_next_leaf(), also make
btrfs_next_leaf() a wrapper of
This patchset can be fetched from github:
https://github.com/adam900710/btrfs-progs/tree/dump_tree_enhance
The main point of this patchset is to make "btrfs ins dump-tree" to
print tree blocks in breadth-first order when level is higher than 2.
The 1st patch is just a minor cleanup, to remove
When printing tree nodes, we output slots like:
key (EXTENT_TREE ROOT_ITEM 0) block 73625600 (17975) gen 16
The number in the parentheses is blockptr / nodesize.
However this number doesn't really do any thing useful.
And in fact for unaligned metadata block group (block group start bytenr
is
On 5.09.2018 04:55, Liu Bo wrote:
> Here we're not releasing any space, but transferring bytes from
> ->bytes_may_use to ->bytes_reserved.
>
> Signed-off-by: Liu Bo
Reviewed-by: Nikolay Borisov
> ---
> v2: Add missing commit log.
>
> fs/btrfs/extent-tree.c | 4
> 1 file changed, 4
23 matches
Mail list logo