Re: Btrfs tragedy: lack of space for metadata leads to loss of fs.

[Austin S Hemmelgarn]

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).

smime.p7s
Description: S/MIME Cryptographic Signature