Current btrfs-check will check qgroup consistency, but even when it
finds something wrong, the return value is still 0.
Fix it by allowing report_qgroups() to return int to indicate qgroup
mismatch, and also add extra logical to return no error if qgroup repair
is successful.
Without this patch,
Current btrfs-check will check qgroup consistency, but even when it
finds something wrong, the return value is still 0.
Fix it by allowing report_qgroups() to return int to indicate qgroup
mismatch, and also add extra logical to return no error if qgroup repair
is successful.
Without this patch,
Since the test case uses run_mustfail(), which is pretty easy pass due to
other unexpected problems, so here an extra run_check() is added to
ensure we don't only report qgroup error, but also fix it without
problem.
Signed-off-by: Qu Wenruo
---
.../032-corrupted-qgroup/qgroup_corrupted.img | Bi
On 2018年04月27日 03:23, je...@suse.com wrote:
> From: Jeff Mahoney
>
> Commit d2c609b834d6 (Btrfs: fix qgroup rescan worker initialization)
> fixed the issue with BTRFS_IOC_QUOTA_RESCAN_WAIT being racy, but
> ended up reintroducing the hang-on-unmount bug that the commit it
> intended to fix addr
Since the test case uses run_mustfail(), which is pretty easy pass due to
other unexpected problems, so here an extra run_check() is added to
ensure we don't only report qgroup error, but also fix it without
problem.
Signed-off-by: Qu Wenruo
---
.../032-corrupted-qgroup/qgroup_corrupted.img | Bi
On 2018年04月30日 11:49, Su Yue wrote:
>
>
> On 04/30/2018 11:15 AM, Qu Wenruo wrote:
>> For btrfs_print_tree(), if nr_items is corrupted, it can easily go
>> beyond extent buffer boundary.
>>
>> Add extra nr_item check, and only print as many valid slots as possible.
>>
>
> Make sense.
>
>> Sig
On 04/30/2018 11:15 AM, Qu Wenruo wrote:
For btrfs_print_tree(), if nr_items is corrupted, it can easily go
beyond extent buffer boundary.
Add extra nr_item check, and only print as many valid slots as possible.
Make sense.
Signed-off-by: Qu Wenruo
---
print-tree.c | 11 ++-
1
On 04/30/2018 11:15 AM, Qu Wenruo wrote:
For btrfs_print_tree() and btrfs_print_leaf(), the usage of fs_info is
mainly for nodesize and sectorsize.
However for nodesize, we can get it from @eb->len without the need for
fs_info at all.
For nodesize, introduce new helper BTRFS_NODEPTR_PER_EXTEN
On 04/30/2018 11:15 AM, Qu Wenruo wrote:
For btrfs_leaf_free_space(), to get leaf data size, we have two way to
get it:
1) leaf->fs_info->nodesize
2) leaf->len
Anyway, we could get rid of @fs_info parameter for
btrfs_leaf_free_space().
And here we choose method 2), as it provides extra benefi
For btrfs_print_tree(), if nr_items is corrupted, it can easily go
beyond extent buffer boundary.
Add extra nr_item check, and only print as many valid slots as possible.
Signed-off-by: Qu Wenruo
---
print-tree.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/pr
For btrfs_print_tree() and btrfs_print_leaf(), the usage of fs_info is
mainly for nodesize and sectorsize.
However for nodesize, we can get it from @eb->len without the need for
fs_info at all.
For nodesize, introduce new helper BTRFS_NODEPTR_PER_EXTENT_BUFFER() to
get nodesize from @eb directly.
For btrfs_leaf_free_space(), to get leaf data size, we have two way to
get it:
1) leaf->fs_info->nodesize
2) leaf->len
Anyway, we could get rid of @fs_info parameter for
btrfs_leaf_free_space().
And here we choose method 2), as it provides extra benefit to get leaf
free space without initializing
On 2018年04月29日 22:08, Michael Wade wrote:
> Hi Qu,
>
> Got this error message:
>
> ./btrfs inspect dump-tree -b 20800943685632 /dev/md127
> btrfs-progs v4.16.1
> bytenr mismatch, want=20800943685632, have=3118598835113619663
> ERROR: cannot read chunk root
> ERROR: unable to open /dev/md127
>
On 2018年04月29日 22:08, Michael Wade wrote:
> Hi Qu,
>
> Got this error message:
>
> ./btrfs inspect dump-tree -b 20800943685632 /dev/md127
> btrfs-progs v4.16.1
> bytenr mismatch, want=20800943685632, have=3118598835113619663
> ERROR: cannot read chunk root
> ERROR: unable to open /dev/md127
>
On Sun, Apr 29, 2018 at 5:16 PM, Theodore Y. Ts'o wrote:
> On Sun, Apr 29, 2018 at 03:55:39PM -0500, Vijay Chidambaram wrote:
>> In the spirit of clarifying fsync behavior, we have one more case
>> where we'd like to find out what should be expected.
>>
>> Consider this:
>>
>> Mkdir A
>> Creat A/b
On Sun, Apr 29, 2018 at 03:55:39PM -0500, Vijay Chidambaram wrote:
> In the spirit of clarifying fsync behavior, we have one more case
> where we'd like to find out what should be expected.
>
> Consider this:
>
> Mkdir A
> Creat A/bar
> Fsync A/bar
> Rename A to B
> Fsync B/bar
> -- Crash --
>
>
Dear Sir/Madam,
I am Sgt Swanson Dennis, I have a good business proposal for you.
There are no risks involved and it is easy. Please reply for briefs
and procedures.
Best regards,
Sgt Swanson Dennis
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message
> On Fri, Apr 27, 2018 at 3:53 PM, Theodore Y. Ts'o wrote:
>> On Fri, Apr 27, 2018 at 11:33:29AM -0600, Chris Mason wrote:
>>> My goal for the fsync tree log was to make it just do the right thing most
>>> of the time. We mostly got there, thanks to a ton of fixes and test cases
>>> from Filipe.
On 4/29/18 6:13 AM, David Sterba wrote:
> On Fri, Apr 27, 2018 at 03:18:17PM -0400, Jeff Mahoney wrote:
>> On 4/27/18 2:56 PM, je...@suse.com wrote:
>>> From: Jeff Mahoney
>>>
>>> Commit 2e1932e6a38 (btrfs-progs: build: simplify version tracking)
>>> started m4_chomp to strip the newlines from the
On Fri, Apr 27, 2018 at 03:18:17PM -0400, Jeff Mahoney wrote:
> On 4/27/18 2:56 PM, je...@suse.com wrote:
> > From: Jeff Mahoney
> >
> > Commit 2e1932e6a38 (btrfs-progs: build: simplify version tracking)
> > started m4_chomp to strip the newlines from the version file. m4_chomp
> > was introduce
On 2018年04月29日 17:59, David C. Partridge wrote:
> Here's the correct output - I mistyped inspect so I got the help output
> instead of the dump-tree!!!
>
> David
The archive is corrupted.
Would you mind to upload it google drive/dropbox?
Thanks,
Qu
>
> -Original Message-
> From: Da
On 2018年04月29日 17:55, David C. Partridge wrote:
> Yes I did use seek=
>
> I attach the new dump-tree - it seems very short compared to the last one you
> requested ???
Well, my fault, wrong spell.
# btrfs inspect dump-tree -t extent
Which should give a lengthy dump.
Thanks,
Qu
>
> Dave
>
Yes I did use seek=
I attach the new dump-tree - it seems very short compared to the last one you
requested ???
Dave
-Original Message-
From: Qu Wenruo [mailto:quwenruo.bt...@gmx.com]
Sent: 29 April 2018 10:36
To: David C. Partridge; linux-btrfs@vger.kernel.org
Subject: Re: Problems wi
On 2018年04月29日 17:20, David C. Partridge wrote:
> Here is the result of btrfs check after applying the patch
Doesn't work as expected.
Did you apply the patched tree block with "seek="?
If so, please dump extent tree again to verify if the modification is
done correct.
# btrfs inspect dump-tr
On 2018年04月29日 16:59, Michael Wade wrote:
> Ok, will it be possible for me to install the new version of the tools
> on my current kernel without overriding the existing install? Hesitant
> to update kernel/btrfs as it might break the ReadyNAS interface /
> future firmware upgrades.
>
> Perhaps
Here is the result of btrfs check after applying the patch
Dave
-Original Message-
From: Qu Wenruo [mailto:quwenruo.bt...@gmx.com]
Sent: 29 April 2018 09:36
To: David C. Partridge
Subject: Re: Problems with btrfs
Here is the patched binary tree block.
You could apply them by the followi
Ok, will it be possible for me to install the new version of the tools
on my current kernel without overriding the existing install? Hesitant
to update kernel/btrfs as it might break the ReadyNAS interface /
future firmware upgrades.
Perhaps I could grab this:
https://github.com/kdave/btrfs-progs/
On 2018年04月29日 16:11, Michael Wade wrote:
> Thanks Qu,
>
> Please find attached the log file for the chunk recover command.
Strangely, btrfs chunk recovery found no extra chunk beyond current
system chunk range.
Which means, it's chunk tree corrupted.
Please dump the chunk tree with latest bt
Brendan Hide posted on Sat, 28 Apr 2018 09:30:30 +0200 as excerpted:
> My real worry is that I'm currently reading at 2.79GB/s (see result
> above and below) without compression when my hardware *should* limit it
> to 2.0GB/s. This tells me either `sync` is not working or my benchmark
> method is
David C. Partridge posted on Sat, 28 Apr 2018 15:09:07 +0100 as excerpted:
> To what level of btrfs-progs do you recommend I should upgrade once my
> corrupt FS is fixed? What is the kernel pre-req for that?
>
> Would prefer not to build from source ... currently running Ubuntu
> 16.04LTS
The w
In preivous patch:
Btrfs: kill trans in run_delalloc_nocow and btrfs_cross_ref_exist
We avoid starting btrfs transaction and get this information from
fs_info->running_transaction directly.
When accessing running_transaction in check_delayed_ref, there's a
chance that current transaction will be f
31 matches
Mail list logo