From: Marc Joliet <marcec@gmx.de>
To: linux-btrfs@vger.kernel.org
Subject: Re: trim not working and irreparable errors from btrfsck
Date: Fri, 14 Aug 2015 10:05:55 +0200 [thread overview]
Message-ID: <20150814100555.24c01e93@thetick> (raw)
In-Reply-To: <CAJCQCtR_9L4oBOcLAfL1gC4UVt1APOU6iSkJ3TBrEcUb0hT3qg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1798 bytes --]
Am Thu, 13 Aug 2015 17:14:36 -0600
schrieb Chris Murphy <lists@colorremedies.com>:
> On Thu, Aug 13, 2015 at 3:23 AM, Marc Joliet <marcec@gmx.de> wrote:
>
> > 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?
>
> Since I'm not having this problem with my SSD, I'm not in a position
> to provide any meaningful information for such a report.
>
> The bug should whether this problem is reproducible with ext4 and XFS
> on the same device, and the complete details of the stacking (if this
> is not the full device or partition of it; e.g. if LVM, md, or
> encryption is between fs and physical device). And also the bug should
> include full dmesg as attachment, and strace of the fstrim command
> that results in 0 bytes trimmed. And probably separate bugs for each
> make/model of SSD, with the bug including make/model and firmware
> version.
>
> Right now I think there's no status because a.) no bug report and b.)
> not enough information.
I was mainly asking because apparently there *is* a patch that helps some
people affected by this, but nobody ever commented on it. Perhaps there's a
reason for that, but I found it curious. (I see now that it was submitted in
early January, in the thread "[PATCH V2] Btrfs: really fix trim 0 bytes after a
device delete".)
I can open a bug (I mean, that's part of being a user of btrfs at this stage),
I'm just surprised that nobody else has.
BTW, is there a way to tell if the "discard" mount option does anything? I'm
curious about whether it could behave differently.
--
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-14 8:06 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
2015-08-13 23:14 ` Chris Murphy
2015-08-14 8:05 ` Marc Joliet [this message]
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=20150814100555.24c01e93@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.