Qu Wenruo wrote:
> If you're really interesting in whether your fs has skinny metadata
> enabled, you can check btrfs-show-super output.
> Like the following output indicates skinny metadata:
> --
> incompat_flags0x161
> ( MIXED_BACKREF |
>
Ángel González wrote on 2016/02/16 23:21 +0100:
Which should be my next steps?
Try btrfs-progs 4.4 to see if all these false alert goes a way.
Thanks,
Qu
Thanks!
Those "errors" are indeed gone after updating btrfs-progs from 4.3.1 to
4.4. Sorry for the fuss.
It's strange though if
> > Which should be my next steps?
> >
>
> Try btrfs-progs 4.4 to see if all these false alert goes a way.
>
> Thanks,
> Qu
Thanks!
Those "errors" are indeed gone after updating btrfs-progs from 4.3.1 to
4.4. Sorry for the fuss.
It's strange though if it was supposed to only happen with
Ángel González wrote on 2016/02/16 01:14 +0100:
Hello everybody
I have a btrfs filesystem [probably] created with btrfs-progs 4.3.1
that is also spewing some hundred of thousand «bad extent [x, y), type
mismatch with chunk» messages on btrfsck.
In fact, there is not only one false alert.
Hello everybody
I have a btrfs filesystem [probably] created with btrfs-progs 4.3.1
that is also spewing some hundred of thousand «bad extent [x, y), type
mismatch with chunk» messages on btrfsck.
The data seems to be fine, so I expect it to be some kind of false
positive. Still, there seems to
Laurent Bonnaud wrote on 2015/12/14 13:47 +0100:
On 11/12/2015 15:21, Laurent Bonnaud wrote:
The next step will we to run a "btrfs scrub" to check if data loss did happen...
Scrubbing is now finished and it detected no errors.
Glad to hear that.
Your fs should be OK now.
Thanks,
Qu
On 11/12/2015 15:21, Laurent Bonnaud wrote:
> The next step will we to run a "btrfs scrub" to check if data loss did
> happen...
Scrubbing is now finished and it detected no errors.
--
Laurent.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message
Laurent Bonnaud wrote on 2015/12/11 15:21 +0100:
On 04/12/2015 01:47, Qu Wenruo wrote:
[run btrfsck]
I did that, too with an old btrfsck version (4.0) and it found the following
errors.
Then I did a btrfsck --repair, and I have been able to complete my "du -s" test.
The next step will we
On 04/12/2015 01:47, Qu Wenruo wrote:
> [run btrfsck]
I did that, too with an old btrfsck version (4.0) and it found the following
errors.
Then I did a btrfsck --repair, and I have been able to complete my "du -s" test.
The next step will we to run a "btrfs scrub" to check if data loss did
On 04/12/2015 01:47, Qu Wenruo wrote:
> The chunk mismatch problem should be resolved already, as the patch is merged
> in david's devel branch.
Great ! I am looking forward to a new release with this bug fix...
> But for the kernel abort transaction, I'm sorry there is no good clue yet.
>
On 25/11/2015 10:05, Laurent Bonnaud wrote:
>> > Nice reproducer.
>> > Is it 100% reproducible or has a chance to reproduce?
> I tried a second time and got a similar kernel backtrace.
Hi,
any news since you downloaded my FS image ?
I kept my corrupted FS in case you wanted more info, but
Laurent Bonnaud wrote on 2015/12/03 18:13 +0100:
On 25/11/2015 10:05, Laurent Bonnaud wrote:
Nice reproducer.
Is it 100% reproducible or has a chance to reproduce?
I tried a second time and got a similar kernel backtrace.
Hi,
any news since you downloaded my FS image ?
I kept my
On 25/11/2015 00:46, Qu Wenruo wrote:
> The size seems small enough, I'll try to download it as it's super useful to
> debug it.
Thanks !
> Nice reproducer.
> Is it 100% reproducible or has a chance to reproduce?
I tried a second time and got a similar kernel backtrace.
> BTW, did you
Christoph Anton Mitterer wrote on 2015/11/24 19:25 +0100:
On Tue, 2015-11-24 at 13:35 +0800, Qu Wenruo wrote:
Hopes you didn't wait too long.
No worries, didn't hold my breath ;)
The fixing patch is CCed to you, or you can get it from patchwork:
https://patchwork.kernel.org/patch/7687611/
On Wed, 2015-11-25 at 08:59 +0800, Qu Wenruo wrote:
> Did you use the complied btrfsck? Or use the system btrfsck by
> mistake?
I'm pretty sure cause I already did the whole procedure twice, but let
me repeat and record it here just to be 100% sure:
$ make clean
Cleaning
$ md5sum cmds-check.c
Hey again.
So it seems that data-b is always fine (well at least three times in a
row) and data-old-a always gives errors.
including e.g:
bad extent [3067663679488, 3067663695872), type mismatch with chunk
bad extent [3067663876096, 3067663892480), type mismatch with chunk
bad extent
On 11/24/2015 09:15 PM, Laurent Bonnaud wrote:
On 23/11/2015 02:00, Qu Wenruo wrote:
Considering the size, I'd like not to touch the dump, metadata is over 5G,
It is only 2GB once compressed :>.
The size seems small enough, I'll try to download it as it's super
useful to debug it.
On Tue, Nov 24, 2015 at 08:46:03AM +0800, Qu Wenruo wrote:
>
>
> Christoph Anton Mitterer wrote on 2015/11/23 19:12 +0100:
> > On Mon, 2015-11-23 at 09:10 +0800, Qu Wenruo wrote:
> >> Also, you won't want compiler to do extra optimization
> > I did the following:
> > $ export CFLAGS="-g -O0
On Tue, 2015-11-24 at 13:35 +0800, Qu Wenruo wrote:
> Hopes you didn't wait too long.
No worries, didn't hold my breath ;)
> The fixing patch is CCed to you, or you can get it from patchwork:
> https://patchwork.kernel.org/patch/7687611/
Unfortunately that doesn't make the error messages go
On 11/24/2015 09:15 PM, Laurent Bonnaud wrote:
On 23/11/2015 02:00, Qu Wenruo wrote:
Considering the size, I'd like not to touch the dump, metadata is over 5G,
It is only 2GB once compressed :>.
and I think it's not related to on-disk data, but runtime problem like I
mentioned above.
On 11/25/2015 02:25 AM, Christoph Anton Mitterer wrote:
On Tue, 2015-11-24 at 13:35 +0800, Qu Wenruo wrote:
Hopes you didn't wait too long.
No worries, didn't hold my breath ;)
The fixing patch is CCed to you, or you can get it from patchwork:
https://patchwork.kernel.org/patch/7687611/
On 23/11/2015 02:00, Qu Wenruo wrote:
> Considering the size, I'd like not to touch the dump, metadata is over 5G,
It is only 2GB once compressed :>.
> and I think it's not related to on-disk data, but runtime problem like I
> mentioned above.
To test this hypothesis I did the following:
-
On Mon, 2015-11-23 at 09:10 +0800, Qu Wenruo wrote:
> Also, you won't want compiler to do extra optimization
I did the following:
$ export CFLAGS="-g -O0 -Wall -D_FORTIFY_SOURCE=2"
$ ./configure --disable-convert --disable-documentation
So if you want me to get rid of _FORTIFY_SOURCE, please
Christoph Anton Mitterer wrote on 2015/11/24 04:02 +0100:
On Tue, 2015-11-24 at 10:54 +0800, Qu Wenruo wrote:
And it would be even better if you want to be a lab mouse for
incoming fixing patches.
Sure,.. if I get some cheese... and it would be great if you could give
me patches that apply
Christoph Anton Mitterer wrote on 2015/11/23 19:12 +0100:
On Mon, 2015-11-23 at 09:10 +0800, Qu Wenruo wrote:
Also, you won't want compiler to do extra optimization
I did the following:
$ export CFLAGS="-g -O0 -Wall -D_FORTIFY_SOURCE=2"
Wow, I didn't ever know it's possible to override
Christoph Anton Mitterer wrote on 2015/11/24 02:53 +0100:
On Tue, 2015-11-24 at 08:46 +0800, Qu Wenruo wrote:
But there are also some other places like line 4411, 4394 and 4387.
Ah of course, I didn't have a look for further places
$ grep -n "rec->wrong_chunk_type = 1" cmds-check.c
On Tue, 2015-11-24 at 08:46 +0800, Qu Wenruo wrote:
> But there are also some other places like line 4411, 4394 and 4387.
Ah of course, I didn't have a look for further places
$ grep -n "rec->wrong_chunk_type = 1" cmds-check.c
4387: rec->wrong_chunk_type = 1;
4394:
Christoph Anton Mitterer wrote on 2015/11/24 03:48 +0100:
On Tue, 2015-11-24 at 10:09 +0800, Qu Wenruo wrote:
I'll dig further to see what's causing the problem.
I guess you'd prefer if I keep the fs for later verification?
That would be the best.
And it would be even better if you want
On Tue, 2015-11-24 at 10:54 +0800, Qu Wenruo wrote:
> And it would be even better if you want to be a lab mouse for
> incoming fixing patches.
Sure,.. if I get some cheese... and it would be great if you could give
me patches that apply to 4.3.
> (It won't hurt nor destroy your data)
wouldn't
On Tue, 2015-11-24 at 10:09 +0800, Qu Wenruo wrote:
> I'll dig further to see what's causing the problem.
I guess you'd prefer if I keep the fs for later verification?
> Thanks for all the debug info, it really helps a lot!
Well thanks for your efforts as well :)
Chris.
smime.p7s
Description:
Laurent Bonnaud wrote on 2015/11/22 11:17 +0100:
On 22/11/2015 03:04, Qu Wenruo wrote:
If any of you can recompile btrfs-progs and use gdb to debug it,
would anyone please to investigate where did the wrong_chunk_type is
set?
In the mean time my btrfs filesystem degraded
Nov 20 18:10:53
to do the trick.
Thanks,
Qu
... but the error message ("bad extent [5993525264384, 5993525280768),
type mismatch with chunk") doesn't seem to be printed at that stage...
If I continue, it goes for a while:
Breakpoint 1, check_extent_type (rec=rec@entry=0x884290) at cmds-check.c:4423
On 22/11/2015 03:04, Qu Wenruo wrote:
> If any of you can recompile btrfs-progs and use gdb to debug it,
> would anyone please to investigate where did the wrong_chunk_type is
> set?
In the mean time my btrfs filesystem degraded
Nov 20 18:10:53 irancy kernel: BTRFS: device label sauvegarde-IUT2
b library "/lib/x86_64-linux-gnu/libthread_db.so.1".
... in fact reaches that breakpoint:
Breakpoint 1, check_extent_type (rec=rec@entry=0x884290) at cmds-check.c:4423
4423 }
... but the error message ("bad extent [5993525264384, 5993525280768),
type mismatch with chunk"
Hi Lukas, Laurent and Christoph,
If any of you can recompile btrfs-progs and use gdb to debug it, would
anyone please to investigate where did the wrong_chunk_type is set?
It is in the function check_extent_type():
--
/* Check if the type of extent matches with its chunk */
static void
On Fri, 2015-11-20 at 17:23 +0100, Laurent Bonnaud wrote:
> So here is the output of "btrfs-debug-tree -t 2 " in case it may
Gosh... 15M via mail?! o.O
Anyway an update from my side...
I've copied all data from the fs in question to a new btrfs,... done
under Linux 4.2.6 and btrfs-progs v4.3.
No
On 11/21/2015 03:24 AM, Christoph Anton Mitterer wrote:
On Fri, 2015-11-20 at 17:23 +0100, Laurent Bonnaud wrote:
So here is the output of "btrfs-debug-tree -t 2 " in case it may
Gosh... 15M via mail?! o.O
Anyway an update from my side...
I've copied all data from the fs in question to a
On 11/21/2015 01:47 PM, Qu Wenruo wrote as excerpted:
> Hard to say, but we'd better keep an eye on this issue.
> At least, if it happens again, we should know if it's related to
> something like newer kernel or snapshots.
I can confirm the initially describe behavior of "btrfs check" and
reading
On Sun, 2015-11-15 at 09:29 +0800, Qu Wenruo wrote:
> > > If type is wrong, all the extents inside the chunk should be
> > > reported
> > > as
> > > mismatch type with chunk.
> > Isn't that the case? At least there are so many reported extents...
>
> If you posted all the output
Sure, I posted
在 2015年11月14日 10:29, Christoph Anton Mitterer 写道:
On Sat, 2015-11-14 at 09:22 +0800, Qu Wenruo wrote:
Manually checked they all.
thanks a lot :-)
Strangely, they are all OK... although it's a good news for you.
Oh man... you're s mean ;-D
They are all tree blocks and are all in
I just got the backup disk back, also btrfs, which was made via
send/receive...
It has the same errors during fsck.
The main disk still hasn't found any file (apart from a few, others for
which none of my hash sums were stored at all) that doesn't verify.
So I guess there's definitely some bug
On Fri, 2015-11-13 at 07:05 +, Duncan wrote:
> 8 TiB disks -- are those the disk-managed SMR "archive" disks I've
> read
> about on a number of threads?
Yes... but...
> If so, that hardware is almost certainly the cause, as they're known
> to
> be problematic on current kernels. While most
在 2015年11月13日 05:51, Christoph Anton Mitterer 写道:
Hey.
I get these errors on fsck'ing a btrfs:
bad extent [5993525264384, 5993525280768), type mismatch with chunk
bad extent [5993525280768, 5993525297152), type mismatch with chunk
bad extent [5993525297152, 5993525313536), type mismatch
On Sat, 2015-11-14 at 09:22 +0800, Qu Wenruo wrote:
> Manually checked they all.
thanks a lot :-)
> Strangely, they are all OK... although it's a good news for you.
Oh man... you're s mean ;-D
> They are all tree blocks and are all in metadata block group.
and I guess that's...
I've uploaded the full output of btrfs check on that device to:
http://christoph.anton.mitterer.name/tmp/public/cbec6446-898b-11e5-90a4-502690aa641f.xz
there are nearly 600k of these error lines... WTF?!
Also, the filesystem still mounts (without any errors to dmesg)
Any help would be
Hey.
I get these errors on fsck'ing a btrfs:
bad extent [5993525264384, 5993525280768), type mismatch with chunk
bad extent [5993525280768, 5993525297152), type mismatch with chunk
bad extent [5993525297152, 5993525313536), type mismatch with chunk
bad extent [5993529442304, 5993529458688), type
.
I get these errors on fsck'ing a btrfs:
bad extent [5993525264384, 5993525280768), type mismatch with chunk
bad extent [5993525280768, 5993525297152), type mismatch with chunk
bad extent [5993525297152, 5993525313536), type mismatch with chunk
bad extent [5993529442304, 5993529458688), type
Christoph Anton Mitterer posted on Fri, 13 Nov 2015 04:57:29 +0100 as
excerpted:
> As I've said I have these two 8TiB disks... one which is basically the
> master with loads of precious data, the other being a backup from the
> master, regularly created with incremental btrfs send/receive.
8 TiB
On Fri, 2015-11-13 at 11:23 +0800, Qu Wenruo wrote:
> No, "-t 2" means only dump extent tree, no privacy issues at all.
> Since only numeric inode/snapshot number and offset inside file.
> Or I'll give you a warning on privacy.
>
> No file name at all, just try it yourself.
I'm preparing it...
Hey.
On Fri, 2015-11-13 at 10:13 +0800, Qu Wenruo wrote:
> Like this one, if any extent type doesn't match with its chunk, like
> metadata extent in a data chunk, btrfsck will report like that.
So these errors... are they anything serious? I.e. like data
loss/corruption? Or is it more a
Christoph Anton Mitterer wrote on 2015/11/13 03:26 +0100:
Hey.
On Fri, 2015-11-13 at 10:13 +0800, Qu Wenruo wrote:
Like this one, if any extent type doesn't match with its chunk, like
metadata extent in a data chunk, btrfsck will report like that.
So these errors... are they anything
On Fri, 2015-11-13 at 11:23 +0800, Qu Wenruo wrote:
> No, "-t 2" means only dump extent tree, no privacy issues at all.
> Since only numeric inode/snapshot number and offset inside file.
> Or I'll give you a warning on privacy.
Done...
On Fri, 2015-11-13 at 10:52 +0800, Qu Wenruo wrote:
> You can provide the output of "btrfs-debug-tree -t 2 " to help
> further debug.
> It would be quite big, so it's better to zip it.
That would contain all the filenames, right? Hmm that could be
problematic because of privacy issues...
>
And I should perhaps mention one more thing:
As I've said I have these two 8TiB disks... one which is basically the
master with loads of precious data, the other being a backup from the
master, regularly created with incremental btrfs send/receive.
Everytime I did this (which is every two months
Christoph Anton Mitterer wrote on 2015/11/13 04:03 +0100:
On Fri, 2015-11-13 at 10:52 +0800, Qu Wenruo wrote:
You can provide the output of "btrfs-debug-tree -t 2 " to help
further debug.
It would be quite big, so it's better to zip it.
That would contain all the filenames, right? Hmm that
55 matches
Mail list logo
