Le 2017-01-03 07:11, Qu Wenruo a écrit :
Hello, what’s the status of my report since last October ?
thanks,
Sorry for the late reply.
I tried your image but...
It's so slow, no matter the mode I'm using.
So I'm not sure if it's a deadlock since lowmem mode still takes
several minuts and ju
At 01/02/2017 07:29 AM, none wrote:
Le 2016-10-27 03:11, Qu Wenruo a écrit :
At 10/26/2016 07:52 PM, none wrote:
Le 2016-10-26 03:43, Qu Wenruo a écrit :
Unfortunately, low memory mode is right here.
If btrfs-image dump the image correctly, your extent tree is really
screwed up.
And how badl
Le 2016-10-27 03:11, Qu Wenruo a écrit :
At 10/26/2016 07:52 PM, none wrote:
Le 2016-10-26 03:43, Qu Wenruo a écrit :
Unfortunately, low memory mode is right here.
If btrfs-image dump the image correctly, your extent tree is really
screwed up.
And how badly it is screwed up?
It only contains
At 10/26/2016 07:52 PM, none wrote:
Le 2016-10-26 03:43, Qu Wenruo a écrit :
Unfortunately, low memory mode is right here.
If btrfs-image dump the image correctly, your extent tree is really
screwed up.
And how badly it is screwed up?
It only contains the basic block group info.
Almost empty
Le 2016-10-26 03:43, Qu Wenruo a écrit :
Unfortunately, low memory mode is right here.
If btrfs-image dump the image correctly, your extent tree is really
screwed up.
And how badly it is screwed up?
It only contains the basic block group info.
Almost empty, without any really useful EXTENT_IT
Le 2016-10-26 03:43, Qu Wenruo a écrit :
Unfortunately, low memory mode is right here.
If btrfs-image dump the image correctly, your extent tree is really
screwed up.
And how badly it is screwed up?
It only contains the basic block group info.
Almost empty, without any really useful EXTENT_IT
Unfortunately, low memory mode is right here.
If btrfs-image dump the image correctly, your extent tree is really
screwed up.
And how badly it is screwed up?
It only contains the basic block group info.
Almost empty, without any really useful EXTENT_ITEM/METADATA_ITEM.
You can check it by btr
Le 2016-10-25 05:04, Qu Wenruo a écrit :
At 10/25/2016 01:54 AM, none wrote:
So do you mean lowmem is also low cpu ?
Not sure, but lowmem is high IO.
And by design, it won't cause dead look unless there is a looping tree
block. But that will be detected by check_tree_block().
So, it just avoi
At 10/25/2016 01:54 AM, none wrote:
So do you mean lowmem is also low cpu ?
Not sure, but lowmem is high IO.
And by design, it won't cause dead look unless there is a looping tree
block. But that will be detected by check_tree_block().
So, it just avoids any possible dead loop AFAIK.
Ind
You could try to use --mode lowmem, which doesn't ever use any loop to
get next block, but iterating trees.
Current in mainline btrfs-progs, the low memory mode code only checks
extent/chunk trees, file/subvolume trees are still checked by original mode.
You could try the devel branch from Da
Hello,
I have the following bug
https://bugzilla.kernel.org/show_bug.cgi?id=178781 in btrfs check, is
there a way to recover my filesystem in clean state without formatting
or using btrsfck ? Of course, the point is no longer need the files
which are damaged.
So is there a way to recover a btr
11 matches
Mail list logo
