From: Marc Joliet <marcec@gmx.de>
To: linux-btrfs@vger.kernel.org
Subject: Re: trim not working and irreparable errors from btrfsck
Date: Thu, 13 Aug 2015 11:23:31 +0200 [thread overview]
Message-ID: <20150813112331.297d15f6@thetick> (raw)
In-Reply-To: <B7F2379062E32745A8651FBDB20F64595D45D284@Server.waterlogic.com.au>
[-- Attachment #1: Type: text/plain, Size: 4767 bytes --]
Am Sun, 21 Jun 2015 07:21:03 +0000
schrieb Paul Jones <paul@pauljones.id.au>:
> > -----Original Message-----
> > From: Lutz Euler [mailto:lutz.euler@freenet.de]
> > Sent: Sunday, 21 June 2015 12:11 AM
> > To: Christian; Paul Jones; Austin S Hemmelgarn
> > Cc: linux-btrfs@vger.kernel.org
> > Subject: RE: trim not working and irreparable errors from btrfsck
> >
> > 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
>
> I tried the test and the numbers I was getting seemed reasonable, however I went ahead and applied the patch anyway. Trim now works correctly!
>
> Thanks,
> Paul.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
Speaking as a user, since "fstrim -av" still always outputs 0 bytes trimmed
on my system: what's the status of this? Did anybody ever file a bug report?
There was also that other thread, "fstrim not working on one of three BTRFS
filesystems", that also never went anywhere.
I take it from this that my SSD has been running untrimmed for quite a while
now?
(FWIW, queued trim is blocked by my kernel (it's "forced_unqueued"), but fstrim
should still start an unqueued trim, right?)
# uname -a
Linux thetick 4.1.4-gentoo #1 SMP PREEMPT Tue Aug 4 21:58:41 CEST 2015 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ AuthenticAMD GNU/Linux
# btrfs --version
btrfs-progs v4.1.2
# btrfs filesystem show
Label: 'MARCEC_ROOT' uuid: 0267d8b3-a074-460a-832d-5d5fd36bae64
Total devices 1 FS bytes used 56.59GiB
devid 1 size 107.79GiB used 69.03GiB path /dev/sda1
Label: 'MARCEC_STORAGE' uuid: 472c9290-3ff2-4096-9c47-0612d3a52cef
Total devices 2 FS bytes used 597.75GiB
devid 1 size 931.51GiB used 600.03GiB path /dev/sdc
devid 2 size 931.51GiB used 600.03GiB path /dev/sdb
Label: 'MARCEC_BACKUP' uuid: f97b3cda-15e8-418b-bb9b-235391ef2a38
Total devices 1 FS bytes used 807.59GiB
devid 1 size 976.56GiB used 837.06GiB path /dev/sdd2
btrfs-progs v4.1.2
# btrfs filesystem df /
Data, single: total=65.00GiB, used=54.83GiB
System, single: total=32.00MiB, used=16.00KiB
Metadata, single: total=4.00GiB, used=1.76GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
Greetings
--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup
[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2015-08-13 9:43 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
2015-06-21 7:21 ` Paul Jones
2015-08-13 9:23 ` Marc Joliet [this message]
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=20150813112331.297d15f6@thetick \
--to=marcec@gmx.de \
--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 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.