All of lore.kernel.org
 help / color / mirror / Atom feed
From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: "Marc MERLIN" <marc@merlins.org>,
	"Miguel Negrão" <miguel.negrao-lists@friendlyvirus.org>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Btrfs tragedy: lack of space for metadata leads to loss of fs.
Date: Tue, 25 Aug 2015 11:43:10 -0400	[thread overview]
Message-ID: <55DC8D0E.802@gmail.com> (raw)
In-Reply-To: <20150825145922.GE20179@merlins.org>

[-- Attachment #1: Type: text/plain, Size: 1870 bytes --]

On 2015-08-25 10:59, Marc MERLIN wrote:
> On Tue, Aug 25, 2015 at 01:44:12PM +0000, Miguel Negrão wrote:
>> Hi list,
>>
>> This weekend had my first btrfs horror story.
>>
>> system: 3.13.0-49-lowlatency, btrfs-progs v4.1.2
>
> Sorry to say, but that's a very old kernels with many btrfs bugs, some
> did lead to corruption.
>
>> A disclaimer: I know 3.13 is very out of date, but I the requirement of
>> keeping kernel up to date clashes with my requirement of keeping a stable
>> system. At the moment I can't disturb my system as I'm doing important work,
>
> Unfortunately you have conflicting goals.
>
>> upgrading kernel requires upgrading ubuntu, which will upgrade a lot of
>> packages and might lead to problems which I don't have time to fix. One
>
> You're doing it wrong :)
> Upgrade/compile your own kernel without upgrading the OS.
>
>> block group 32...... flags 36'). This is a OCZ vertex 3, a quite fast SSD.
>
> I've had 5 (yes 5, I replaced my drive 4 times) OCZ Vertex 4 drives, and
> they all gave me corruption with btrfs on unclean power down. The last
> one didn't work any better, I just gave up and went to Samsung EVO 840
> and those have been fine.
Yeah, it's not just unclean power down that can cause this though, one 
of my friends wouldn't believe me when I told him his Vertex 3 was the 
cause of his problems till I did the following from a known good copy of 
SystemRescueCD (sda was his SSD):
dd if=/dev/urandom of=/dev/sda
dd if=/dev/zero of=/dev/sda
xxd dev/sda

and it returned thousands of blocks of non-zero data in just the first 
16G.  I wouldn't trust an OCZ drive for anything except scratch space. 
(Personally I'm a fan of Crucial SSD's due to their lower price point 
than the Samsung and Intel SSD's but almost equivalent performance and 
data integrity, but to each his own).


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]

  parent reply	other threads:[~2015-08-25 15:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-25 13:44 Btrfs tragedy: lack of space for metadata leads to loss of fs Miguel Negrão
2015-08-25 14:00 ` Austin S Hemmelgarn
2015-08-25 14:26   ` Miguel Negrão
2015-08-25 14:53     ` Austin S Hemmelgarn
2015-08-25 14:59 ` Marc MERLIN
2015-08-25 15:24   ` Miguel Negrão
2015-08-25 15:43   ` Austin S Hemmelgarn [this message]
2015-08-25 15:17 ` Matt Ruffalo
2015-08-25 15:53   ` Miguel Negrão

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=55DC8D0E.802@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=marc@merlins.org \
    --cc=miguel.negrao-lists@friendlyvirus.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.