All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bernd Schubert <bernd.schubert@fastmail.fm>
To: Lutz Vieweg <lvml@5t9.de>, 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:18:52 +0100	[thread overview]
Message-ID: <547392AC.4050302@fastmail.fm> (raw)
In-Reply-To: <54738F2D.8000909@5t9.de>



On 11/24/2014 09:03 PM, Lutz Vieweg wrote:
> 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...
> 

It just tries to trim one sector more than the device actually has. So
as far as I can tell it is harmless.

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

Thread overview: 19+ 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 17:09     ` Lutz Vieweg
2014-11-21 21:20     ` Mike Frysinger
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:30         ` Lutz Vieweg
2014-11-24 19:43         ` Bernd Schubert
2014-11-24 19:43           ` Bernd Schubert
2014-11-24 20:03           ` Lutz Vieweg
2014-11-24 20:03             ` Lutz Vieweg
2014-11-24 20:18             ` Bernd Schubert [this message]
2014-11-24 21:24     ` Dave Chinner
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=547392AC.4050302@fastmail.fm \
    --to=bernd.schubert@fastmail.fm \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@oss.sgi.com \
    --cc=lvml@5t9.de \
    --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 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.