Re: trim not working and irreparable errors from btrfsck

[Marc Joliet <marcec@gmx.de>]

[-- 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 --]