All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: lutz.euler@freenet.de (Lutz Euler)
To: Christian <cdysthe@gmail.com>, Paul Jones <paul@pauljones.id.au>,
	Austin S Hemmelgarn <ahferroin7@gmail.com>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: RE: trim not working and irreparable errors from btrfsck
Date: Sat, 20 Jun 2015 16:11:18 +0200	[thread overview]
Message-ID: <21893.29830.540787.159202@localhost.localdomain> (raw)
In-Reply-To: <B7F2379062E32745A8651FBDB20F64595D40C1BD@Server.waterlogic.com.au>

Hi Christian, Paul and Austin,

Christian wrote:
> However, fstrim still gives me "0 B (0 bytes) trimmed, so that may be
> another problem. Is there a way to check if trim works?

Paul wrote:
> I've got the same problem. I've got 2 SSDs with 2 partitions in RAID1,
> fstrim always works on the 2nd partition but not the first. There are
> no errors on either filesystem that I know of, but the first one is
> root so I can't take it offline to run btrfs check.

Austin wrote:
> I'm seeing the same issue here, but with a Crucial brand SSD.
> Somewhat interestingly, I don't see any issues like this with BTRFS on
> top of LVM's thin-provisioning volumes, or with any other filesystems,
> so I think it has something to do with how BTRFS is reporting unused
> space or how it is submitting the discard requests.

Probably you all suffer from the same problem I had a few years ago.
It is a bug in how btrfs implements fstrim.

To check whether you are a victim of this bug simply run:

# btrfs-debug-tree /dev/whatever | grep 'FIRST_CHUNK_TREE CHUNK_ITEM'

where /dev/whatever is a device of your filesystem, and interrupt after
the first several output lines with C-c. (Officially the filesystem
should be unmounted when running btrfs-debug-tree, but that is not
necessary as we only read from it and the relevant data doesn't change
very often.)

You get something like:

  item 2 key (FIRST_CHUNK_TREE CHUNK_ITEM 0)
  item 3 key (FIRST_CHUNK_TREE CHUNK_ITEM 12947816448)
  item 4 key (FIRST_CHUNK_TREE CHUNK_ITEM 14021558272)
  ...

(This output is from an old version of btrfs-progs. I understand newer
version are more verbose, but you should nevertheless easily be able to
interpret the output).

If the first number different from 0 (here, the 12947816448) is larger
than the sum of the sizes of the devices the filesystem consists of,
bingo.

This has been discussed already in the past and there is a patch.

Please see for the patch:
http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg40618.html

and for the background:
http://comments.gmane.org/gmane.comp.file-systems.btrfs/15597

Kind regards,

Lutz Euler
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in

  parent reply	other threads:[~2015-06-20 14:29 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-16 14:18 trim not working and irreparable errors from btrfsck Christian
2015-06-16 21:14 ` Chris Murphy
     [not found]   ` <55816E7B.5040905@gmail.com>
2015-06-17 14:22     ` Chris Murphy
2015-06-17 14:33       ` Christian
2015-06-17 15:28         ` Chris Murphy
2015-06-17 15:40           ` Christian
2015-06-17 17:17             ` Austin S Hemmelgarn
2015-06-18  5:25               ` Duncan
2015-08-14 15:11                 ` Jeff Mahoney
2015-06-20 14:11               ` Lutz Euler [this message]
2015-06-21  7:21                 ` Paul Jones
2015-08-13  9:23                   ` Marc Joliet
2015-08-13 23:14                     ` Chris Murphy
2015-08-14  8:05                       ` Marc Joliet
2015-08-14  8:15                         ` Marc Joliet
2015-08-14 10:51                         ` Paul Jones
2015-06-18  2:20         ` Paul Jones
2015-06-18  4:15           ` Chris Murphy
2015-06-18  4:19             ` Chris Murphy

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=21893.29830.540787.159202@localhost.localdomain \
    --to=lutz.euler@freenet.de \
    --cc=ahferroin7@gmail.com \
    --cc=cdysthe@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=paul@pauljones.id.au \
    /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.