From: "Lukáš Czerner" <lczerner@redhat.com>
To: Andreas Hartmann <andihartmann@01019freenet.de>
Cc: "Lukáš Czerner" <lczerner@redhat.com>,
util-linux@vger.kernel.org, "Karel Zak" <kzak@redhat.com>
Subject: Re: Questions concerning fstrim and online discard.
Date: Tue, 16 Oct 2012 21:07:26 +0200 (CEST) [thread overview]
Message-ID: <alpine.LFD.2.00.1210162056290.18184@localhost> (raw)
In-Reply-To: <507D8B15.5050004@01019freenet.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4396 bytes --]
On Tue, 16 Oct 2012, Andreas Hartmann wrote:
> Date: Tue, 16 Oct 2012 18:28:05 +0200
> From: Andreas Hartmann <andihartmann@01019freenet.de>
> To: Lukáš Czerner <lczerner@redhat.com>
> Cc: Andreas Hartmann <andihartmann@01019freenet.de>,
> util-linux@vger.kernel.org, Karel Zak <kzak@redhat.com>
> Subject: Re: Questions concerning fstrim and online discard.
>
> Hello Lukas!
>
> I'm really happy about your detailed comments! Thanks a lot!
>
> On Tue, 16 Oct 2012, Andreas Hartmann wrote: Lukáš Czerner wrote:
> > On Thu, 4 Oct 2012, Andreas Hartmann wrote:
> >
> >> Date: Thu, 4 Oct 2012 06:47:36 +0200
> >> From: Andreas Hartmann <andihartmann@01019freenet.de>
> >> To: util-linux@vger.kernel.org
> >> Subject: Questions concerning fstrim and online discard.
> >> Resent-Date: Mon, 15 Oct 2012 16:10:43 +0200
> >> Resent-From: Karel Zak <kzak@redhat.com>
> >> Resent-To: Lukas Czerner <lczerner@redhat.com>
> >>
> >> Hello!
> >>
> >> Please, may I ask you some questions because I'm a little bit confused
> >> about the behaviour of fstrim and online discard (ext4)?
> >>
> >>
> >> I'm using the following configuration / partitioning with a SSD
> >> (Controller: SF-2281; Corsair Force GT 240GB):
> >>
> >> - dm_crypt: cryptsetup luksOpen - version 1.4.1, device-mapper
> >> version 1.02.75
> >
> > Hi Andreas,
> >
> > I hope that you realize that using discard with dm_crypt is not
> > safe.
>
> I know about this problem. My understanding is: trim usually writes 0 to
> the free addresses, hence it is possible to see which addresses are used
> and which are unused.
This is not exactly right. TRIM does not write anything to the
device, but you can read zeroes (or some other values, see bellow) when
reading previously trimmed blocks. The reason being that when when
it's tirmmed firmware does not actually need to read data from the flash.
>
> The SF-2281 controller seems not to write zero to the addresses, hence
> the problem shouldn't be with this controller? Or did I got something wrong?
>
> cat /sys/block/sda/queue/discard_zeroes_data
> 0
That's just one case. IIRC the device can return zeores after trim (which
will be advertised through sysfs interface), some other deterministic data
or pseudorandom data. The device would not be able to always return what
has been there before simply because those blocks might have already been
reused in wear levelling process, so it has to be substituted. And when it
comes to cryptography, all those options are bad.
>
> >
> >> - lvm version 2.02.96
> >> - ext4, option discard; kernel version 3.4.11
> >>
> >> All seems to work fine, I can't see any errors in messages or in dmesg
> >> according trim / discard.
> >
> > The question is what kernel version do you use ?
>
> 3.4.11 :-)
>
> > Currnently we will
> > ignore all errors coming from the online discard including the
> > situation where the device does not support discard.
> >
> > This is not exactly ideal, because we should really inform user that
> > there was an error.
>
> Yes, this would be really important!
>
> > However we should _NOT_ inform user about every
> > discard request failed with EOPNOTSUPP because we can have
> > multi-disk devices where some of the devices support discard and
> > some of the does not, this is perfectly valid situation and kernel
> > should not scream.
>
> Once at the moment the device is mounted would be enough.
>
> > Nevertheless I am going to change things so that we inform use about
> > problem (other than EOPNOTSUPP). And maybe warn once a day that
> > part, or whole device does not support discard at all - I think that
> > this should not hurt.
> >
> >>
> >> Now, I tested fstrim from util-linux version 2.19, and surprisingly got
> >> this unexpected error:
> >>
> >> fstrim: /: FITRIM ioctl failed: Operation not supported
> >
> > Actually kernel version is what matters.
> >
> >>
> >> Why do I get this error? Online discard always seemed to work fine (= I
> >> didn't get any error).
> >
> > Those errors probably got silently dropped so you did not know about
> > them.
>
> But if fstrim works, online discard will work, too? Or is this
> conclusion wrong (ext4)?
Yes, if the file system supports both (which is the case for ext4).
>
> [....]
>
> > I hope it helps.
>
> Yes, it really helped a lot!
>
I am glad to help.
Thanks!
-Lukas
>
> Kind regards,
> Andreas Hartmann
next prev parent reply other threads:[~2012-10-16 19:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-04 4:47 Questions concerning fstrim and online discard Andreas Hartmann
[not found] ` <alpine.LFD.2.00.1210151649540.15261@dhcp-1-104.brq.redhat.com>
2012-10-16 16:28 ` Andreas Hartmann
2012-10-16 19:07 ` Lukáš Czerner [this message]
2012-10-17 17:28 ` Andreas Hartmann
2012-10-17 19:23 ` Milan Broz
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=alpine.LFD.2.00.1210162056290.18184@localhost \
--to=lczerner@redhat.com \
--cc=andihartmann@01019freenet.de \
--cc=kzak@redhat.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).