On Fri, May 13, 2016 at 6:10 AM, Niccolò Belli
wrote:
> On venerdì 13 maggio 2016 13:35:01 CEST, Austin S. Hemmelgarn wrote:
>>
>> The fact that you're getting an OOPS involving core kernel threads
>> (kswapd) is a pretty good indication that either there's a bug elsewhere in
>> the kernel, or tha
On venerdì 13 maggio 2016 13:35:01 CEST, Austin S. Hemmelgarn wrote:
The fact that you're getting an OOPS involving core kernel
threads (kswapd) is a pretty good indication that either there's
a bug elsewhere in the kernel, or that something is wrong with
your hardware. it's really difficult t
On 2016-05-13 07:07, Niccolò Belli wrote:
On giovedì 12 maggio 2016 17:43:38 CEST, Austin S. Hemmelgarn wrote:
That's probably a good indication of the CPU and the MB being OK, but
not necessarily the RAM. There's two other possible options for
testing the RAM that haven't been mentioned yet th
On giovedì 12 maggio 2016 17:43:38 CEST, Austin S. Hemmelgarn wrote:
That's probably a good indication of the CPU and the MB being
OK, but not necessarily the RAM. There's two other possible
options for testing the RAM that haven't been mentioned yet
though (which I hadn't thought of myself un
On Thu, May 12, 2016 at 04:35:24PM +0200, Niccolò Belli wrote:
> When doing the btrfs check I also always do a btrfs scrub and it never found
> any error. Once it didn't manage to finish the scrub because of:
> BTRFS critical (device dm-0): corrupt leaf, slot offset bad:
> block=670597120,root=1, s
On 2016-05-12 10:35, Niccolò Belli wrote:
On lunedì 9 maggio 2016 18:29:41 CEST, Zygo Blaxell wrote:
Did you also check the data matches the backup? btrfs check will only
look at the metadata, which is 0.1% of what you've copied. From what
you've written, there should be a lot of errors in the
On lunedì 9 maggio 2016 18:29:41 CEST, Zygo Blaxell wrote:
Did you also check the data matches the backup? btrfs check will only
look at the metadata, which is 0.1% of what you've copied. From what
you've written, there should be a lot of errors in the data too. If you
have incorrect data but
On Mon, May 9, 2016 at 8:53 AM, Niccolò Belli wrote:
> I cannot manage to survive such annoying workflow for long, so I really hope
> someone will manage to track the bug down soon.
I suggest perseverance :) despite how tedious this is. Btrfs is more
aware of its state than other file systems, s
Hi,
Le 09/05/2016 16:53, Niccolò Belli a écrit :
> On domenica 8 maggio 2016 20:27:55 CEST, Patrik Lundquist wrote:
>> Are you using any power management tweaks?
>
> Yes, as stated in my very first post I use TLP with
> SATA_LINKPWR_ON_BAT=max_performance, but I managed to reproduce the
> bug even
Austin S. Hemmelgarn posted on Mon, 09 May 2016 14:21:57 -0400 as
excerpted:
> This practice evolved out of the fact that the only bad RAM I've ever
> dealt with either completely failed to POST (which can have all kinds of
> interesting symptoms if it's just one module, some MB's refuse to boot,
On 2016-05-09 12:29, Zygo Blaxell wrote:
On Mon, May 09, 2016 at 04:53:13PM +0200, Niccolò Belli wrote:
While trying to find a common denominator for my issue I did lots of backups
of /dev/mapper/cryptroot and I restored them into /dev/mapper/cryptroot
dozens of times (triggering a 150GB+ random
On Mon, May 09, 2016 at 04:53:13PM +0200, Niccolò Belli wrote:
> While trying to find a common denominator for my issue I did lots of backups
> of /dev/mapper/cryptroot and I restored them into /dev/mapper/cryptroot
> dozens of times (triggering a 150GB+ random data write every time), without
> any
On domenica 8 maggio 2016 20:27:55 CEST, Patrik Lundquist wrote:
Are you using any power management tweaks?
Yes, as stated in my very first post I use TLP with
SATA_LINKPWR_ON_BAT=max_performance, but I managed to reproduce the bug
even without TLP. Also in the past week I've alwyas been on A
On 2016-05-07 12:11, Niccolò Belli wrote:
Il 2016-05-07 17:58 Clemens Eisserer ha scritto:
Hi Niccolo,
btrfs + dmcrypt + compress=lzo + autodefrag = corruption at first boot
Just to be curious - couldn't it be a hardware issue? I use almost the
same setup (compress-force=lzo instead of compr
On 7 May 2016 at 18:11, Niccolò Belli wrote:
> Which kind of hardware issue? I did a full memtest86 check, a full
> smartmontools extended check and even a badblocks -wsv.
> If this is really an hardware issue that we can identify I would be more than
> happy because Dell will replace my laptop
On Sat, May 7, 2016 at 9:45 AM, Niccolò Belli wrote:
> btrfs + dmcrypt + compress=lzo + autodefrag = corruption at first boot
> So discard is not the culprit. Will try to remove compress=lzo and
> autodefrag and see if it still happens.
You're making the troubleshooting unnecessarily difficult by
Il 2016-05-07 17:58 Clemens Eisserer ha scritto:
Hi Niccolo,
btrfs + dmcrypt + compress=lzo + autodefrag = corruption at first boot
Just to be curious - couldn't it be a hardware issue? I use almost the
same setup (compress-force=lzo instead of compress-force=lzo) on my
laptop for 2-3 years a
Hi Niccolo,
> btrfs + dmcrypt + compress=lzo + autodefrag = corruption at first boot
Just to be curious - couldn't it be a hardware issue? I use almost the
same setup (compress-force=lzo instead of compress-force=lzo) on my
laptop for 2-3 years and haven't experienced any issues since
~kernel-3.1
btrfs + dmcrypt + compress=lzo + autodefrag = corruption at first boot
So discard is not the culprit. Will try to remove compress=lzo and
autodefrag and see if it still happens.
[ 748.224346] BTRFS error (device dm-0): memmove bogus src_offset 5431
move len 4294962894 len 16384
[ 748.226206
I formatted the partition and copied the content of my previous rootfs to
it. There is no dmcrypt now and mount options are defaults, except for
noatime. After a single boot I got the very same problem as before (fs
corrupted and an infinite loop when doing btrfs check --repair.
I wanted to re
On Thu, May 05, 2016 at 12:36:52PM +0200, Niccolò Belli wrote:
> On giovedì 5 maggio 2016 03:07:37 CEST, Chris Murphy wrote:
> > I suggest using defaults for starters. The only thing in that list
> > that needs be there is either subvolid or subvold, not both. Add in
> > the non-default options onc
On giovedì 5 maggio 2016 03:07:37 CEST, Chris Murphy wrote:
I suggest using defaults for starters. The only thing in that list
that needs be there is either subvolid or subvold, not both. Add in
the non-default options once you've proven the defaults are working,
and add them one at a time.
Yes
Niccolò Belli wrote on 2016/05/05 01:21 +0200:
I really need your help, because it's the second time btrfs ate my data
in a couple of days and I can't use my laptop if I don't find the culprit.
This was the mail I sent a couple of days ago:
https://www.spinics.net/lists/linux-btrfs/msg54754.ht
On Wed, May 4, 2016 at 5:21 PM, Niccolò Belli wrote:
> rw,noatime,compress=lzo,ssd,discard,space_cache,autodefrag,subvolid=257,subvol=/@
I suggest using defaults for starters. The only thing in that list
that needs be there is either subvolid or subvold, not both. Add in
the non-default options
24 matches
Mail list logo