From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: trim not working and irreparable errors from btrfsck
Date: Thu, 18 Jun 2015 05:25:05 +0000 (UTC) [thread overview]
Message-ID: <pan$e2fd3$4225d55d$123c95d2$8d29df22@cox.net> (raw)
In-Reply-To: 5581ABA2.30906@gmail.com
Austin S Hemmelgarn posted on Wed, 17 Jun 2015 13:17:22 -0400 as
excerpted:
> On 2015-06-17 11:40, Christian wrote:
>> On 06/17/2015 11:28 AM, Chris Murphy 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?
>>>
>>> That sounds like maybe your SSD is blacklisted for trim, is all I can
>>> think of. So trim shouldn't be the cause of the problem if it's being
>>> blacklisted. The recent problems appear to be around newer SSDs that
>>> support queue trim and newer kernels that issue queued trim. There
>>> have been some patches related to trim to the kernel, but the
>>> existence of blacklisting and claims of bugs in firmware make it
>>> difficult to test and isolate.
>>>
>>> http://techreport.com/news/28473/some-samsung-ssds-may-suffer-from-a-
buggy-trim-implementation
>>>
>>>
>> This is an Intel SSD in a Lenovo Thinkpad X1 Carbon. Trim worked until
>> a few weeks ago and still works for my small ext4 boot partition (just
>> ran it to check). I will keep looking for a solution. Thanks!
>>
> 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.
FWIW, there's a current btrfs patch in progress that relates to problems
with btrfs trim.
But while I do have SSDs, I purposefully overprovisioned them by nearly
100% (IOW I partitioned only about 55%, the rest is entirely unused), so
trim isn't as critical here as it is for many. I don't use the discard
mount option, and have a systemd timer job setup to automate my fstrims
and don't worry about the output too much, so I haven't been following
the patch progress /that/ closely.
But I do know that recent kernel btrfs trims (either fstrim or discard
mount option triggered) haven't been working as originally intended due
to some bug, and this patch is supposed to fix it.
I'd thus conclude that you're very likely hitting this known issue, and
that either for 4.1 or 4.2 (again, I'm not following progress that
closely, and don't remember for sure if it's in 4.1, altho I've been
running the rcs since rc6 or so), the problem should be fixed as that
patch gets into mainline.
Anyone wishing to investigate further can of course check the list (and/
or possibly the kernel's git log) for discard/trim related patches and
follow the progress once found.
... Actually, just checked myself. Looks like the patches were first
posted on March 30 @ 15:12:17 -0400 or so (that's the time for one of
them). There's one for the discard mount option, and another for FITRIM
(which may or may not be a typo for FSTRIM, I'm not actually sure). Jeff
Mahoney <jeffm@suse.com> author. That should be enough to find the
threads. And I don't see the patches in the late 4.1-rc I'm running so
either my git log search foo is bad or it'll be (at least) 4.2.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2015-06-18 5:26 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 [this message]
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
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='pan$e2fd3$4225d55d$123c95d2$8d29df22@cox.net' \
--to=1i5t5.duncan@cox.net \
--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.