Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

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

Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

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

Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

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

Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

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

Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

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,

Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

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

Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

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

Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

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

Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

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

Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

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,

Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

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+

Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

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 >

Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

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

Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

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

Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

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

Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

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

Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

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

Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

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

Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

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 [

Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

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: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

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

Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

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.

Re: btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

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

btrfs ate my data in just two days, after a fresh install. ram and disk are ok. it still mounts, but I cannot repair

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.html I previously thought the culprit was a bug