From: Claes Fransson <claes.v.fransson@gmail.com>
To: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: bad key ordering - repairable?
Date: Tue, 23 Jan 2018 14:29:26 +0100 [thread overview]
Message-ID: <CAEY8F1pZyqVBhuOK79eOgDX41-vYRdym5hVKoMRcFVV25_WMJA@mail.gmail.com> (raw)
In-Reply-To: <8f74430a-0f72-cd26-ee50-f9b4239b5558@gmail.com>
2018-01-23 13:51 GMT+01:00 Austin S. Hemmelgarn <ahferroin7@gmail.com>:
> On 2018-01-22 21:35, Chris Murphy wrote:
>>
>> On Mon, Jan 22, 2018 at 2:06 PM, Claes Fransson
>> <claes.v.fransson@gmail.com> wrote:
>>>
>>> Hi!
>>>
>>> I really like the features of BTRFS, especially deduplication,
>>> snapshotting and checksumming. However, when using it on my laptop the
>>> last couple of years, it has became corrupted a lot of times.
>>> Sometimes I have managed to fix the problems (at least so much that I
>>> can continue to use the filesystem) with check --repair, but several
>>> times I had to recreate the file system and reinstall the operating
>>> system.
>>>
>>> I am guessing the corruptions might be the results of unclean
>>> shutdowns, mostly after system hangs, but also because of running out
>>> of battery sometimes?
>>
>>
>> I think it's something else because I intentionally and
>> unintentionally do unclean shutdowns (I'm really impatient and I'm a
>> saboteur) on my laptop and I never get corruptions. In 18 months with
>> an HP Spectre which doesn't even have ECC memory, and has an NVMe
>> drive, *and* really remarkable for almost half this time I used the
>> discard mount option which pretty much instantly obliterates unused
>> roots, even when referenced in the super block as backup roots - and
>> yet still zero corruption. No complaints on mount, scrub, or readonly
>> checks. *shrug*
>>
>> Anyway I suspect hardware or power issue. Or even SSD firmware issue.
>
> I would tend to agree here, with one caveat, if it's a laptop that's less
> than 3 years old, you can probably rule out power issues. Some more info on
> the particular system might help identify what's wrong.
Hi,
I boughtThe laptop new in July 2014, but have had corruption issues
with btrfs I think as long as I have been trying it, since the end of
2014 I think. You can find addtitional info about my laptop in my
original post, please let me know if you want som more info.
>>
>>
>>> Furthermore, the power-led has recently started blinking (also when
>>> the power-cable is plugged in), I guess because of an old and bad
>>> battery. Maybe the current corruption also can have something to do
>>> with this? However I almost always run with power cable plugged in in
>>> last year, only on battery a few seconds a few times when moving the
>>> laptop.
>>>
>>> Currently, I can only mount the filesystem readonly, it goes readonly
>>> automatically if I try to mount it normally.
>>
>>
>> Btrfs is confused and doesn't want to make the corruption worse. >
>>>
>>>
>>> Fstab mount options: noatime,autodefrag (I have been using the option
>>> nossd with older kernels one period in the past on the filesystem).
>>>
>>> If it matters, I have been running duperemove many times on the
>>> filesystem since creation.
>>
>>
>> I don't think it's related.
>>
>>
>>>
>>> To test the RAM, I have been running mprime Blend-test for 24 hours
>>> after the corruption without any error or warning.
>>
>>
>> I'm not familiar with it, pretty sure you want this for UEFI:
>>
>> https://www.memtest86.com/download.htm
>>
>> Where you can use that or memtest86+ if the firmware is BIOS based.
>
> Do keep in mind that just because it passes memory checks does not mean it's
> not an issue with the RAM. Memory testers rarely throw false positives, but
> it's pretty common to get false negatives from them.>
Okay, thanks for telling me.
>>>
>>> I have never noticed any corruptions on the NTFS and Ext4 file systems
>>> on the laptop, only on the Btrfs file systems.
>>
>>
>> NTFS and ext4 likely won't notice such corruptions either (although
>> new ext4 volumes any day now will have checksummed metadata by
>> default) as they're weren't designed with such detection in mind.
>
> This is extremely important to understand. BTRFS and ZFS are essentially
> the only filesystems available on Linux that actually validate things enough
> to notice this reliably (ReFS on Windows probably does, and I think whatever
> Apple is calling their new FS does too). Even if ext4 did notice it, it
> would just mark the filesystem for a check and then keep going without doing
> anything else about it (seriously, the default behavior for internal errors
> on ext4 is to just continue like nothing happened and mark the FS for fsck).
Well, personally I think it would be great if I (optionally) could do
that with Btrfs too. Even if it notice me of corruption and I might
even lose e few files, I think it would be good if I could continue to
use the filesystem with normal read/write capabilities, so I wouldnt
need to reinstall the operating system.
Best regards,
Claes
next prev parent reply other threads:[~2018-01-23 13:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-22 21:06 bad key ordering - repairable? Claes Fransson
2018-01-22 21:22 ` Hugo Mills
2018-01-23 13:06 ` Claes Fransson
2018-01-23 18:13 ` Claes Fransson
2018-01-24 0:31 ` Chris Murphy
2018-01-24 19:44 ` Claes Fransson
2018-01-24 23:15 ` Duncan
[not found] ` <CAEY8F1pVrZnf3M6mGJaxogx14ZrJ5CV3++_-y13sTniJ3ds4ww@mail.gmail.com>
2018-01-27 17:42 ` Claes Fransson
2018-01-27 14:54 ` Claes Fransson
2018-01-23 2:35 ` Chris Murphy
2018-01-23 12:51 ` Austin S. Hemmelgarn
2018-01-23 13:29 ` Claes Fransson [this message]
2018-01-24 0:44 ` Chris Murphy
2018-01-24 12:30 ` Austin S. Hemmelgarn
2018-01-24 23:54 ` Chris Murphy
2018-01-25 12:41 ` Austin S. Hemmelgarn
2018-01-23 13:17 ` Claes Fransson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAEY8F1pZyqVBhuOK79eOgDX41-vYRdym5hVKoMRcFVV25_WMJA@mail.gmail.com \
--to=claes.v.fransson@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).