> -----Original Message----- > From: Lutz Euler [mailto:lutz.eu...@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
