3-29.
> >
> > The BUG() moved, but we are still hitting it:
> >
> > [145427.426011][ T5492] BTRFS info (device dm-0): balance: canceled
> > [145427.689964][ T4811] ----[ cut here ]
> > [145427.692498][ T4811] kern
426011][ T5492] BTRFS info (device dm-0): balance: canceled
> [145427.689964][ T4811] [ cut here ]----
> [145427.692498][ T4811] kernel BUG at fs/btrfs/tree-mod-log.c:675!
> [145427.694668][ T4811] invalid opcode: [#1] SMP KASAN PTI
>
89964][ T4811] [ cut here ]
[145427.692498][ T4811] kernel BUG at fs/btrfs/tree-mod-log.c:675!
[145427.694668][ T4811] invalid opcode: [#1] SMP KASAN PTI
[145427.696379][ T4811] CPU: 3 PID: 4811 Comm: crawl_1215 Tainted: G
W 5.12.0-7d1e
[40422.398920][T28995] BTRFS info (device dm-0): balance:
> > > > > canceled
> > > > > [40607.394003][T11577] BTRFS info (device dm-0): balance:
> > > > > start -dlimit=9
> > > > > [40607.398597][T11577] BTRFS info (de
; > > > block group 315676950528 flags data
> > > > [40643.279661][T11577] BTRFS info (device dm-0): found 12686
> > > > extents, loops 1, stage: move data extents
> > > > [40692.752695][T11577] BTRFS info (device dm-0): found 12686
>
, loops 1, stage: move data extents
> > > [40692.752695][T11577] BTRFS info (device dm-0): found 12686
> > > extents, loops 2, stage: update data pointers
> > > [40704.860522][T11577] BTRFS info (device dm-0): relocating block
> > > group 314603208704 flag
T11577] BTRFS info (device dm-0): relocating block
> > group 314603208704 flags data
> > [40704.919977][T19054] [ cut here ]
> > [40704.921895][T19054] kernel BUG at fs/btrfs/ctree.c:1210!
> > [40704.923497][T19054] invalid o
[40692.752695][T11577] BTRFS info (device dm-0): found 12686 extents,
> loops 2, stage: update data pointers
> [40704.860522][T11577] BTRFS info (device dm-0): relocating block
> group 314603208704 flags data
> [40704.919977][T19054] ----[ cut here ]
[40704.919977][T19054] [ cut here ]
[40704.921895][T19054] kernel BUG at fs/btrfs/ctree.c:1210!
[40704.923497][T19054] invalid opcode: [#1] SMP KASAN PTI
[40704.925549][T19054] CPU: 1 PID: 19054 Comm: crawl_335 Tainted: G
W 5.11.0
On 23/01/2021 23:57, Zygo Blaxell wrote:
You don't have enough space to convert metadata yet, and you also don't
have enough space to lock one of your 3 metadata block groups without
running out of global reserve space, so this balance command forces the
filesystem read-only due to lack of space.
subsystem
>>> EXT4-fs (loop1): mounted filesystem without journal. Opts: (null)
>>> EXT4-fs (loop1): mounting ext3 file system using the ext4 subsystem
>>> EXT4-fs (loop1): mounted filesystem with ordered data mode. Opts: (null)
>>> EXT4-fs (loop1): mounted filesy
On Wed, 2019-09-11 at 11:09 +0300, Nikolay Borisov wrote:
>
> On 11.09.19 г. 11:00 ч., Abdul Haleem wrote:
> > On Tue, 2019-09-03 at 13:39 +0300, Nikolay Borisov wrote:
> >>
>
>
>
> >> corresponds to?
> >
> > btrfs_search_slot+0x8e8/0xb80 maps to fs/btrfs/ctree.c:2751
> > write
On 11.09.19 г. 11:00 ч., Abdul Haleem wrote:
> On Tue, 2019-09-03 at 13:39 +0300, Nikolay Borisov wrote:
>>
>> corresponds to?
>
> btrfs_search_slot+0x8e8/0xb80 maps to fs/btrfs/ctree.c:2751
> write_lock_level = BTRFS_MAX_LEVEL;
That doesn't make sense, presumably btrfs_sear
ystem with ordered data mode. Opts: (null)
> > EXT4-fs (loop1): mounted filesystem with ordered data mode. Opts: (null)
> > XFS (loop1): Mounting V5 Filesystem
> > XFS (loop1): Ending clean mount
> > XFS (loop1): Unmounting Filesystem
> > BTRFS: device fsid 7c08f81b-6642-4a06
On Tue, Sep 03, 2019 at 02:25:07PM +0530, Abdul Haleem wrote:
> Greeting's
>
> Mainline kernel panics with LTP/fs_fill-dir tests for btrfs file
> system on my P9 box running mainline kernel 5.3.0-rc5
Is the issue reproducible? And if yes, how reliably? Thanks.
On Tue, Sep 03, 2019 at 02:25:07PM +0530, Abdul Haleem wrote:
> Greeting's
>
> Mainline kernel panics with LTP/fs_fill-dir tests for btrfs file system on my
> P9 box running mainline kernel 5.3.0-rc5
>
> BUG_ON was first introduced by below commit
Well, technically the bug_on was there already
dev/loop1
> BTRFS info (device loop1): disk space caching is enabled
> BTRFS info (device loop1): has skinny extents
> BTRFS info (device loop1): enabling ssd optimizations
> BTRFS info (device loop1): creating UUID tree
> [ cut here ]
> kernel BUG at fs/btrfs/locking.c:7
ed
BTRFS info (device loop1): has skinny extents
BTRFS info (device loop1): enabling ssd optimizations
BTRFS info (device loop1): creating UUID tree
--------[ cut here ]
kernel BUG at fs/btrfs/locking.c:71!
Oops: Exception in kernel mode, sig: 5 [#1]
LE PAGE_SIZE=64K MMU=Hash SMP
Did more digging today. Here is where the -ENOSPC is coming from:
btrfs_run_delayed_refs -> // WARN here
__btrfs_run_delayed_refs ->
btrfs_run_delayed_refs_for_head ->
run_one_delayed_ref ->
run_delayed_data_ref ->
__btrfs_inc_extent_ref ->
insert_extent_backref ->
insert_extent_data_ref
Hi,
I've done a few experiments and here are my findings.
First I probably should describe the filesystem: it is a snapshot
archive, containing a lot of snapshots for 4 subvolumes, totaling 2487
subvolumes/snapshots. There are also a few files (inside the snapshots)
that are probably very fra
size 7.28TiB used 2.71TiB path /dev/sdd1
> > devid2 size 7.28TiB used 22.01GiB path /dev/loop0
> > devid3 size 7.28TiB used 2.69TiB path /dev/sdf1
>
> Indeed - with the loop device attached, I can mount the filesystem rw
> just fine without any mount f
On 06/07/2019 05.51, Qu Wenruo wrote:
The problem also manifests when attempting to rebalance the metadata.
Have you tried to balance just one or two metadata block groups?
E.g using -mdevid or -mvrange?
If I use -mdevid with the device ID of the device I'm trying to remove
(2), I see the cr
On 2019/7/6 下午1:13, Vladimir Panteleev wrote:
[...]
>> I'm not sure if it's the degraded mount cause the problem, as the
>> enospc_debug output looks like reserved/pinned/over-reserved space has
>> taken up all space, while no new chunk get allocated.
>
> The problem happens after replace-ing th
On 06/07/2019 05.01, Qu Wenruo wrote:
After stubbing out btrfs_check_rw_degradable (because btrfs currently
can't realize when it has all drives needed for RAID10),
The point is, btrfs_check_rw_degradable() is already doing per-chunk
level rw degradable checking.
I would highly recommend not t
D10 data to
> RAID1, and then btrfs-device-delete-d one of the missing drives. It
> fails at deleting the second.
>
> The process reached a point where the last missing device shows as
> containing 20 GB of RAID1 metadata. At this point, attempting to delete
> the device causes th
Indeed - with the loop device attached, I can mount the filesystem rw
just fine without any mount flags, with a stock kernel.
OK so what happens now if you try to 'btrfs device remove /dev/loop0' ?
Unfortunately it fails in the same way (warning followed by "kernel
BUG"). The s
I don't disagree in general, however, I did make sure that all data was
> accessible with two devices before proceeding with this endeavor.
Well there's definitely something screwy if Btrfs needs something on a
missing drive, which is indicated by its refusal to remove it from the
volume,
, but this paragraph contradicts my
understanding, especially when you say "correct approach would be
first to convert all RAID 10 to RAID1 and then remove devices but that
wasn't an option"
OK so what did you do, in order, each command, interleaving the
physical device removals.
Well,
On Fri, Jul 5, 2019 at 3:48 PM Chris Murphy wrote:
>
> We need to see a list of commands issued in order, along with the
> physical connected state of each drive. I thought I understood what
> you did from the previous email, but this paragraph contradicts my
> understanding, especially when you s
On Fri, Jul 5, 2019 at 4:20 AM Vladimir Panteleev
wrote:
>
> On 05/07/2019 09.42, Andrei Borzenkov wrote:
> > On Fri, Jul 5, 2019 at 7:45 AM Vladimir Panteleev
> > wrote:
> >>
> >> Hi,
> >>
> >> I'm trying to convert a data=RAID10,metadata=RAID1 (4 disks) array to
> >> RAID1 (2 disks). The array
On Thu, Jul 4, 2019 at 10:39 PM Vladimir Panteleev
wrote:
>
> Hi,
>
> I'm trying to convert a data=RAID10,metadata=RAID1 (4 disks) array to
> RAID1 (2 disks). The array was less than half full, and I disconnected
> two parity drives, leaving two that contained one copy of all data.
There's no par
On 05/07/2019 09.42, Andrei Borzenkov wrote:
On Fri, Jul 5, 2019 at 7:45 AM Vladimir Panteleev
wrote:
Hi,
I'm trying to convert a data=RAID10,metadata=RAID1 (4 disks) array to
RAID1 (2 disks). The array was less than half full, and I disconnected
two parity drives,
btrfs does not have dedic
the device causes the operation to shortly fail with "No space left",
> followed by a "kernel BUG at fs/btrfs/relocation.c:2499!", and the
> "btrfs device delete" command to crash with a segmentation fault.
>
> Here is the information about the filesyste
On 05/07/2019 04.39, Vladimir Panteleev wrote:
The process reached a point where the last missing device shows as
containing 20 GB of RAID1 metadata. At this point, attempting to delete
the device causes the operation to shortly fail with "No space left",
followed by a "kernel
device shows as
containing 20 GB of RAID1 metadata. At this point, attempting to delete
the device causes the operation to shortly fail with "No space left",
followed by a "kernel BUG at fs/btrfs/relocation.c:2499!", and the
"btrfs device delete" command to crash with a
On Mon, Jun 10, 2019 at 04:14:04PM -0700, Eric Biggers wrote:
> On Thu, Jun 07, 2018 at 06:52:13PM +0200, David Sterba wrote:
> > On Thu, Jun 07, 2018 at 06:28:02PM +0200, Dmitry Vyukov wrote:
> > > > Normally the GFP_NOFS allocations do not fail so I think the fuzzer
> > > > environment is tuned t
On Thu, Jun 07, 2018 at 06:52:13PM +0200, David Sterba wrote:
> On Thu, Jun 07, 2018 at 06:28:02PM +0200, Dmitry Vyukov wrote:
> > > Normally the GFP_NOFS allocations do not fail so I think the fuzzer
> > > environment is tuned to allow that, which is fine for coverage but does
> > > not happen in
On 2019/5/29 下午9:23, Wèi Cōngruì wrote:
> I upgraded the kernel to 5.1.5.
> Got the same error with the command "btrfs device remove 4 ." again.
>
It a known bug and is going to be fixed by this patch:
https://patchwork.kernel.org/patch/10955321/
The backport will happen soon, but I'm afraid it
I upgraded the kernel to 5.1.5.
Got the same error with the command "btrfs device remove 4 ." again.
wer loss.
The stack trace:
[34926.797727] [ cut here ]
[34926.797731] kernel BUG at fs/btrfs/relocation.c:2595!
[34926.797744] invalid opcode: [#1] PREEMPT SMP PTI
[34926.797750] CPU: 0 PID: 16275 Comm: btrfs Not tainted 5.1.4-arch1-1-ARCH #1
[34926.797754] Hardware name:
gt; [ 1645.268105] BTRFS info (device dm-5): relocating block group 7039576178688
> flags data|raid1
> [ 1645.959683] ----[ cut here ]
> [ 1645.959684] kernel BUG at fs/btrfs/relocation.c:1413!
> [ 1645.959695] invalid opcode: [#1] PREEMPT SMP NOPTI
> [ 1645.95972
group 7044005363712
flags system|raid1
[ 1644.403175] BTRFS info (device dm-5): found 35 extents
[ 1645.268105] BTRFS info (device dm-5): relocating block group 7039576178688
flags data|raid1
[ 1645.959683] [ cut here ]
[ 1645.959684] kernel BUG at fs/btrfs/relocation.c
red by automatic
background balance.
Thanks,
Qu
>
> [ 600.078204] kernel BUG at fs/btrfs/relocation.c:1413!
> [ 600.078215] invalid opcode: [#1] PREEMPT SMP PTI
> [ 600.078220] CPU: 5 PID: 4010 Comm: btrfs Tainted: P OE
> 5.1.3-arch1-1-ARCH #1
> [ 600.078222] Har
I attempted to start a balance on Linux 5.1.3. The process crashed
and I got this in dmesg:
[ 600.078204] kernel BUG at fs/btrfs/relocation.c:1413!
[ 600.078215] invalid opcode: [#1] PREEMPT SMP PTI
[ 600.078220] CPU: 5 PID: 4010 Comm: btrfs Tainted: P OE
5.1.3-arch1-1-ARCH #1
On 2019/4/24 下午8:28, Gregory Malloff wrote:
>
> Hello,
>
> After 7 days, BTRFS crashed again with the same error:
>
> [Tue Apr 23 21:59:40 2019] [ cut here ]
> [Tue Apr 23 21:59:40 2019] kernel BUG at fs/btrfs/ctree.c:3230!
> [Tue Apr 2
Hello,
After 7 days, BTRFS crashed again with the same error:
[Tue Apr 23 21:59:40 2019] [ cut here ]
[Tue Apr 23 21:59:40 2019] kernel BUG at fs/btrfs/ctree.c:3230!
[Tue Apr 23 21:59:40 2019] invalid opcode: [#1] SMP PTI
[Tue Apr 23 21:59:40 2019] CPU: 0 PID
On 11/18/2017 12:48 PM, Hans van Kranenburg wrote:
>
> So, who wants to help?
>
> 1. Find a test system that you can crash.
> 2. Create a test filesystem with some data.
> 3. Run with 4.14? (makes the most sense I think)
> 4. Continuously feed the data to balance and send everything to /dev/null
On 11/18/2017 12:48 PM, Hans van Kranenburg wrote:
>
> So, who wants to help?
>
> 1. Find a test system that you can crash.
> 2. Create a test filesystem with some data.
> 3. Run with 4.14? (makes the most sense I think)
> 4. Continuously feed the data to balance and send everything to /dev/null
On 11/18/2017 10:40 AM, Roman Mamedov wrote:
> On Sat, 18 Nov 2017 02:08:46 +0100
> Hans van Kranenburg wrote:
>
>> It's using send + balance at the same time. There's something that makes
>> btrfs explode when you do that.
>>
>> It's not new in 4.14, I have seen it in 4.7 and 4.9 also, various
>
Roman Mamedov wrote:
On Sat, 18 Nov 2017 02:08:46 +0100
Hans van Kranenburg wrote:
It's using send + balance at the same time. There's something that makes
btrfs explode when you do that.
It's not new in 4.14, I have seen it in 4.7 and 4.9 also, various
different explosions in kernel log. Sin
On Sat, 18 Nov 2017 02:08:46 +0100
Hans van Kranenburg wrote:
> It's using send + balance at the same time. There's something that makes
> btrfs explode when you do that.
>
> It's not new in 4.14, I have seen it in 4.7 and 4.9 also, various
> different explosions in kernel log. Since that happen
info (device sdb3): found 2405 extents
[ 3495.408630] BTRFS info (device sdb3): found 2405 extents
[ 3498.161144] [ cut here ]
[ 3498.161150] kernel BUG at
/home/kernel/COD/linux/fs/btrfs/ctree.c:1856!
[ 3498.161264] invalid opcode: [#1] SMP
(...)
[ 3498.164523]
b3): found 2405 extents
> [ 3495.408630] BTRFS info (device sdb3): found 2405 extents
> [ 3498.161144] [ cut here ]--------
> [ 3498.161150] kernel BUG at /home/kernel/COD/linux/fs/btrfs/ctree.c:1856!
> [ 3498.161264] invalid opcode: [#1] SMP
> [ 3498.161363] Modu
tents
[ 3498.161144] [ cut here ]
[ 3498.161150] kernel BUG at
/home/kernel/COD/linux/fs/btrfs/ctree.c:1856!
[ 3498.161264] invalid opcode: [#1] SMP
[ 3498.161363] Modules linked in: nf_log_ipv6 nf_log_ipv4 nf_log_common
xt_LOG xt_multiport xt_conntrack xt_nat binfmt_misc
On 11/17/17 18:48, Marc MERLIN wrote:
> On Thu, Nov 16, 2017 at 09:53:15PM -0800, Marc MERLIN wrote:
>>> I suggest that you try lvmcache instead. It's much more flexible than
>>> bcache,
>>> does pretty much the same job, and has much less of the "hacky" feel to it.
>>
>> I can read up on it, it's
On Thu, Nov 16, 2017 at 09:53:15PM -0800, Marc MERLIN wrote:
> > I suggest that you try lvmcache instead. It's much more flexible than
> > bcache,
> > does pretty much the same job, and has much less of the "hacky" feel to it.
>
> I can read up on it, it's going to be a big pain to convert from o
On Fri, Nov 17, 2017 at 10:41:48AM +0500, Roman Mamedov wrote:
> On Thu, 16 Nov 2017 16:12:56 -0800
> Marc MERLIN wrote:
>
> > On Thu, Nov 16, 2017 at 11:32:33PM +0100, Holger Hoffstätte wrote:
> > > Don't pop the champagne just yet, I just read that apprently 4.14 broke
> > > bcache for some peo
On Thu, 16 Nov 2017 16:12:56 -0800
Marc MERLIN wrote:
> On Thu, Nov 16, 2017 at 11:32:33PM +0100, Holger Hoffstätte wrote:
> > Don't pop the champagne just yet, I just read that apprently 4.14 broke
> > bcache for some people [1]. Not sure how much that affects you, but it might
> > well make thi
On Thu, Nov 16, 2017 at 01:45:51PM -0800, Marc MERLIN wrote:
> On Thu, Nov 16, 2017 at 06:27:44PM +0100, Holger Hoffstätte wrote:
> > On 11/16/17 18:07, Marc MERLIN wrote:
> > > Sorry, was missing the kernel number in the subject, just fixed that.
> > >
> > > On Thu, Nov 16, 2017 at 09:04:45AM -08
On Thu, Nov 16, 2017 at 11:32:33PM +0100, Holger Hoffstätte wrote:
> Don't pop the champagne just yet, I just read that apprently 4.14 broke
> bcache for some people [1]. Not sure how much that affects you, but it might
> well make things worse. Yeah, I know, wonderful.
Oh my, that's actually pret
On 11/16/17 22:45, Marc MERLIN wrote:
(snip)
>> This BUG() was recently removed and seems to be caused by some kind
>> of persistent corruption, which is seen as invalid inline extent.
>> See [1], [2] for details. Maybe you can backport them?
>> Alternatively just give 4.14 a whirl, it's great.
>>
On Thu, Nov 16, 2017 at 06:27:44PM +0100, Holger Hoffstätte wrote:
> On 11/16/17 18:07, Marc MERLIN wrote:
> > Sorry, was missing the kernel number in the subject, just fixed that.
> >
> > On Thu, Nov 16, 2017 at 09:04:45AM -0800, Marc MERLIN wrote:
> >> My server now reboots every 20mn or so, wit
On 11/16/17 18:07, Marc MERLIN wrote:
> Sorry, was missing the kernel number in the subject, just fixed that.
>
> On Thu, Nov 16, 2017 at 09:04:45AM -0800, Marc MERLIN wrote:
>> My server now reboots every 20mn or so, with this.
>> Sadly another BUG_ON() and it won't even tell me which filesystem
nt_inline_ref, offset);
> BUG();
> return 0;
> }
>
>
>
> [ 1399.728735] [ cut here ]
> [ 1399.744149] kernel BUG at fs/btrfs/ctree.h:1802!
> [ 1399.759400] invalid opcode: [#1] PREEMPT SMP
> [ 1399.774892] Modules linked in: veth ip6table_filter ip
urn sizeof(struct btrfs_extent_data_ref) +
offsetof(struct btrfs_extent_inline_ref, offset);
BUG();
return 0;
}
[ 1399.728735] [ cut here ]
[ 1399.744149] kernel BUG at fs/btrfs/ctree.h:1802!
[ 1399.759400] invalid opcode: [#1] P
> Please skip that patch, as the check timing has its problem.
>
Okay, I'll skip the patch and run the tests hereafter. thanks.
Cheers,
Lakshmipathi.G
http://www.giis.co.in http://www.webminal.org
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a mess
3 ip-172-31-32-145.us-west-2.compute.internal kernel:
> BTRFS info (device xvdf): leaf 4400742400 total ptrs 0 free space
> 16283
> Nov 06 05:08:23 ip-172-31-32-145.us-west-2.compute.internal kernel:
> assertion failed: 0, file: fs/btrfs/disk-io.c, line: 540
> Nov 06 05:08:23 ip-172-31-3
kernel:
> BTRFS info (device xvdf): leaf 4400742400 total ptrs 0 free space
> 16283
> Nov 06 05:08:23 ip-172-31-32-145.us-west-2.compute.internal kernel:
> assertion failed: 0, file: fs/btrfs/disk-io.c, line: 540
> Nov 06 05:08:23 ip-172-31-32-145.us-west-2.compute.internal kernel
btrfs/disk-io.c, line: 540
Nov 06 05:08:23 ip-172-31-32-145.us-west-2.compute.internal kernel:
[ cut here ]
Nov 06 05:08:23 ip-172-31-32-145.us-west-2.compute.internal kernel:
kernel BUG at fs/btrfs/ctree.h:3457!
Nov 06 05:08:23 ip-172-31-32-145.us-west-2.compute.internal k
Yes, the patch works. Enabled both CONFIG_BTRFS_FS_CHECK_INTEGRITY
and CONFIG_BTRFS_FS_RUN_SANITY_TESTS.
And applied above patch. This method also resolved the issue. thanks.
Cheers,
Lakshmipathi.G
http://www.giis.co.in http://www.webminal.org
--
To unsubscribe from this list: send the line "
> BTW, it would be better to see if this patch also solves your problem.
>
> https://patchwork.kernel.org/patch/10038011/
Okay sure, let me apply this patch and check the results.
Cheers,
Lakshmipathi.G
http://www.giis.co.in http://www.webminal.org
--
To unsubscribe from this list: send the
BTW, it would be better to see if this patch also solves your problem.
https://patchwork.kernel.org/patch/10038011/
Thanks,
Qu
On 2017年11月03日 12:00, Lakshmipathi.G wrote:
> After disabling FS_CHECK_INTEGRITY and FS_RUN_SANITY_TESTS in the
> config. Now the issue resolved. thanks.
>
> cast: http
After disabling FS_CHECK_INTEGRITY and FS_RUN_SANITY_TESTS in the
config. Now the issue resolved. thanks.
cast: https://asciinema.org/a/Dy6eHhhWPEIxotVbVUBWrhFeF
Cheers,
Lakshmipathi.G
http://www.giis.co.in http://www.webminal.org
On Thu, Nov 2, 2017 at 12:55 PM, Lakshmipathi.G
wrote:
> Ok
Okay thanks, I'll disable above mentioned entry in kernel config and
run the tests.
Will get back with updated results.
Cheers,
Lakshmipathi.G
http://www.giis.co.in http://www.webminal.org
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to
On 2017年11月02日 13:50, Lakshmipathi.G wrote:
>>
>> I'll try to reproduce it with FS_CHECK_INTEGRITY enabled.
>>
>
> Okay thanks for the details. Here's the kernel config file which hits
> this issue:
> https://github.com/Lakshmipathi/btrfsqa/blob/master/setup/config/kernel.config#L3906
Although
>
> I'll try to reproduce it with FS_CHECK_INTEGRITY enabled.
>
Okay thanks for the details. Here's the kernel config file which hits
this issue:
https://github.com/Lakshmipathi/btrfsqa/blob/master/setup/config/kernel.config#L3906
thanks!
Cheers,
Lakshmipathi.G
http://www.giis.co.in http://
On 2017年11月02日 13:19, Lakshmipathi.G wrote:
> Hi.
>
> I'm constantly hitting this bug while running btrfs-progs:fsck-test:012 .
> Screencast: https://asciinema.org/a/wQxZjCeVvX2kVqKjVBGyR0klq
>
> Logged more details: https://bugzilla.kernel.org/show_bug.cgi?id=197587
> Anyone else got this issu
Hi.
I'm constantly hitting this bug while running btrfs-progs:fsck-test:012 .
Screencast: https://asciinema.org/a/wQxZjCeVvX2kVqKjVBGyR0klq
Logged more details: https://bugzilla.kernel.org/show_bug.cgi?id=197587
Anyone else got this issue or something wrong with my test environment?
Cheers,
I'm guessing this is related.
I noticed my tv wasn't recording to my drive and when I tried to touch
a file on the drive, my console become unresponsive.
Trying to reboot took like 5 minutes to even stop the processes and in
the end couldn't unmount the drive and I had to cut the power to
finally g
43:46 dd kernel: [ cut here ]
Nov 01 09:43:46 dd kernel: kernel BUG at fs/btrfs/ctree.c:3182!
Nov 01 09:43:46 dd kernel: Internal error: Oops - BUG: 0 [#1] SMP ARM
Nov 01 09:43:46 dd kernel: Modules linked in: nf_conntrack_netlink
nfnetlink cmac ccm ppp_deflate ppp_async p
=72.30GiB
Metadata, single: total=1.53GiB, used=0.00B
GlobalReserve, single: total=512.00MiB, used=0.00B
[617994.948036] [ cut here ]
[617994.948040] kernel BUG at fs/btrfs/ctree.c:3182!
[617994.952786] invalid opcode: [#1] SMP
[617994.956896] Modules linked in: ipmi_devintf
On Wed, Sep 20, 2017 at 02:53:57PM +0200, David Sterba wrote:
> On Tue, Sep 19, 2017 at 10:12:39AM -0600, Liu Bo wrote:
> > On Tue, Sep 19, 2017 at 05:07:25PM +0200, David Sterba wrote:
> > > On Tue, Sep 19, 2017 at 11:32:46AM +, Paul Jones wrote:
> > > > > This 'mirror 0' looks fishy, (as mirr
On Tue, Sep 19, 2017 at 10:12:39AM -0600, Liu Bo wrote:
> On Tue, Sep 19, 2017 at 05:07:25PM +0200, David Sterba wrote:
> > On Tue, Sep 19, 2017 at 11:32:46AM +, Paul Jones wrote:
> > > > This 'mirror 0' looks fishy, (as mirror comes from
> > > > btrfs_io_bio->mirror_num,
> > > > which should
On Tue, Sep 19, 2017 at 05:07:25PM +0200, David Sterba wrote:
> On Tue, Sep 19, 2017 at 11:32:46AM +, Paul Jones wrote:
> > > This 'mirror 0' looks fishy, (as mirror comes from
> > > btrfs_io_bio->mirror_num,
> > > which should be at least 1 if raid1 setup is in use.)
> > >
> > > Not sure if
On Tue, Sep 19, 2017 at 11:32:46AM +, Paul Jones wrote:
> > This 'mirror 0' looks fishy, (as mirror comes from btrfs_io_bio->mirror_num,
> > which should be at least 1 if raid1 setup is in use.)
> >
> > Not sure if 4.13.2-gentoo made any changes on btrfs, but can you please
> > verify with the
> -Original Message-
> From: Liu Bo [mailto:bo.li@oracle.com]
> Sent: Tuesday, 19 September 2017 3:10 AM
> To: Paul Jones
> Cc: linux-btrfs@vger.kernel.org
> Subject: Re: kernel BUG at fs/btrfs/extent_io.c:1989
>
>
> This 'mirror 0' looks fish
Am Mon, 18 Sep 2017 20:30:41 +0200
schrieb Holger Hoffstätte :
> On 09/18/17 19:09, Liu Bo wrote:
> > This 'mirror 0' looks fishy, (as mirror comes from
> > btrfs_io_bio->mirror_num, which should be at least 1 if raid1 setup
> > is in use.)
> >
> > Not sure if 4.13.2-gentoo made any changes on bt
On 09/18/17 19:09, Liu Bo wrote:
> This 'mirror 0' looks fishy, (as mirror comes from
> btrfs_io_bio->mirror_num, which should be at least 1 if raid1 setup is
> in use.)
>
> Not sure if 4.13.2-gentoo made any changes on btrfs, but can you
No, it did not; Gentoo always strives to be as close to ma
m, which should be at least 1 if raid1 setup is
in use.)
Not sure if 4.13.2-gentoo made any changes on btrfs, but can you
please verify with the upstream kernel, say, v4.13?
Thanks,
-liubo
> [ 174.761986] [ cut here ]
> [ 174.761987] kernel BUG a
csum 0xdbbb090f expected csum 0x74d6a9b2 mirror 0
[ 174.761924] BTRFS warning (device dm-15): csum failed root 7692 ino 534939
off 5639217152 csum 0xdbbb090f expected csum 0x74d6a9b2 mirror 0
[ 174.761986] [ cut here ]
[ 174.761987] kernel BUG at fs/btrfs/extent_io.c
On 2017-08-11 05:57, Piotr Pawłow wrote:
Hello,
So 4.10 isn't /too/ far out of range yet, but I'd strongly consider
upgrading (or downgrading to 4.9 LTS) as soon as it's reasonably
convenient, before 4.13 in any case. Unless you prefer to go the
distro support route, of course.
I used to stic
Hello,
> So 4.10 isn't /too/ far out of range yet, but I'd strongly consider
> upgrading (or downgrading to 4.9 LTS) as soon as it's reasonably
> convenient, before 4.13 in any case. Unless you prefer to go the
> distro support route, of course.
I used to stick to latest kernels back when btrf
Piotr Pawłow posted on Mon, 07 Aug 2017 15:26:16 +0200 as excerpted:
> # uname -a
> Linux pps 4.10.0-30-generic #34-Ubuntu SMP
> Mon Jul 31 19:38:17 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
This is a general principles reply and chances are wouldn't help with
your issue since the spread isn't /to
evice dm-1): stripe index math
went horribly wrong, got stripe_index=2176876031, num_stripes=2
sie 07 04:45:06 pps kernel: BTRFS info (device dm-1): csum failed ino 1340360
extent 5370531217408 csum 716315696 wanted 722897355 mirror -2118091264
sie 07 04:45:06 pps kernel: kernel BUG at
/build/linux-H5
# btrfs fi df /media/camino/
Data, RAID1: total=39.75TiB, used=39.75TiB
System, RAID1: total=43.12MiB, used=6.69MiB
Metadata, RAID1: total=54.00GiB, used=51.55GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
dmesg log:
[ 419.531939] [ cut here ]
[ 419.531941] kernel BUG
Hi,
I'm replacing a btrfs device that was set up as a partition with one
that is a whole disk.
The replace is getting stuck at the 53% mark with errors: kernel BUG at
/home/kernel/COD/linux/fs/btrfs/extent_io.c:2328
More info below -- rebooting and letting replace continue seems t
On Fri, May 19, 2017 at 06:25:22PM -0700, Marc MERLIN wrote:
> On Sat, May 20, 2017 at 12:57:09AM +, Hugo Mills wrote:
> >I think from the POV of removing these BUG_ONs, it doesn't matter
> > which FS causes them. "All" you need to know is where the error
> > happened. From there, you can (
On Sat, May 20, 2017 at 12:57:09AM +, Hugo Mills wrote:
>I think from the POV of removing these BUG_ONs, it doesn't matter
> which FS causes them. "All" you need to know is where the error
> happened. From there, you can (in theory) work out what was wrong and
> handle it more elagantly tha
On Fri, May 19, 2017 at 05:47:48PM -0700, Marc MERLIN wrote:
> On Sat, May 20, 2017 at 12:37:47AM +, Hugo Mills wrote:
> > > Can I make another plea for just removing all those BUG/BUG_ON?
> > > They really have no place in production code, there is no excuse for a
> > > filesystem to bring dow
On Sat, May 20, 2017 at 12:37:47AM +, Hugo Mills wrote:
> > Can I make another plea for just removing all those BUG/BUG_ON?
> > They really have no place in production code, there is no excuse for a
> > filesystem to bring down the entire and in the process not even tell you
> > which of your f
1 - 100 of 1089 matches
Mail list logo
