util-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lutz Vieweg <lvml@5t9.de>
To: Bernd Schubert <bernd.schubert@fastmail.fm>,
	linux-fsdevel@vger.kernel.org
Cc: util-linux@vger.kernel.org, linux-xfs@oss.sgi.com
Subject: Re: fstrim on newly created filesystem tries to discard data beyond the last sector of a device
Date: Mon, 24 Nov 2014 21:03:57 +0100	[thread overview]
Message-ID: <54738F2D.8000909@5t9.de> (raw)
In-Reply-To: <54738A6A.40906@fastmail.fm>

On 11/24/2014 08:43 PM, Bernd Schubert wrote:
>> Then there's another idea: The device is a SATA SSD, but attached
>> to a SAS2 expander chip on the backplane of the server (LSI SAS2X28)
>> which in turn is connected to a LSI SAS HBA 9207-4i4e.
>> could maybe, just maybe, the TRIM command be modified wrongly
>> on its way through these / their respective drivers?
>
> Yeah, it is a known issue with LSI firmware.
>
> http://osdir.com/ml/dm-devel/2013-09/msg00126.html

I must admit that I have difficulties understanding what this
email thread is ultimately telling: Does it mean LSI firmware
actually tampers with TRIM commands such that they would discard
other ranges than those intended? (In which case using TRIM
over any such LSI device would be very dangerous.)
Or does is mean the capabilities of some SSDs to discard data
are mis-reported? And if so, in the sense that the kernel might
not be able to discard data at all, or in the sense that data
is discarded, but the kernel sends additional commands that the
device cannot understand?

After all, if it's just an annoying error message that I can
ignore, I wouldn't mind. But if TRIM via LSI means "data loss",
I would of course have to take measures against this...

Regards,

Lutz Vieweg




  reply	other threads:[~2014-11-24 20:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-10 16:07 fstrim: "fitrim ioctl failed: input/output error" -> "Logical block address out of range" Lutz Vieweg
2014-11-18 10:32 ` fstrim tries to discard data beyond the last sector of a device Lutz Vieweg
2014-11-18 11:03   ` Karel Zak
2014-11-21 16:44     ` Lutz Vieweg
2014-11-21 17:09   ` fstrim on newly created filesystem " Lutz Vieweg
2014-11-21 21:20     ` Mike Frysinger
2014-11-24  9:23       ` Karel Zak
2014-11-24 12:25     ` Lukáš Czerner
2014-11-24 19:30       ` Lutz Vieweg
2014-11-24 19:43         ` Bernd Schubert
2014-11-24 20:03           ` Lutz Vieweg [this message]
2014-11-24 20:18             ` Bernd Schubert
2014-11-24 21:24     ` Dave Chinner

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=54738F2D.8000909@5t9.de \
    --to=lvml@5t9.de \
    --cc=bernd.schubert@fastmail.fm \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@oss.sgi.com \
    --cc=util-linux@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).