Martin Steigerwald | 18 Feb 13:39 2012
Picon

Re: brtfs on top of dmcrypt with SSD. No corruption iff write cache off?

Sorry, I forget to keep Cc´s, different lists, different habits.

To Milan Broz: Well now I noticed that you linked to your own blog entry. 
Please do not take my below statements personally - I might have written 
them a bit harshly. Actually I do not really know whether your statement 
that TRIM is overrated is correct, but before believing that TRIM does not 
give much advantage, I would like to see at least some evidence of any 
sort, cause for me my explaination below that it should make a difference 
at least seems logical to me.

Am Montag, 13. Februar 2012 schrieb Marc MERLIN:
> On Mon, Feb 13, 2012 at 12:47:54AM +0100, Milan Broz wrote:
> > On 02/12/2012 11:32 PM, Marc MERLIN wrote:
> > >Actually I had one more question.
> > >
> > >I read this page:
> > >http://www.redhat.com/archives/dm-devel/2011-July/msg00042.html
> > >
> > >I'm not super clear if with 3.2.5 kernel, I need to pass the special
> > >allow_discards option for brtfs and dm-crypt to be safe together, or
> > >whether
> > >they now talk through an API and everything "just works" :)
> > 
> > If you want discards to be supported in dmcrypt, you have to enable
> > it manually.
> > 
> > The most comfortable way is just use recent cryptsetup and add
> > --allow-discards option to luksOpen command.
> > 
> > It will be never enabled by default in dmcrypt for security reasons
> > http://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html
> 
> Thanks for the answer.
> I knew that it created some security problems but I had not yet found
> the page you just gave, which effectively states that TRIM isn't
> actually that big a win on recent SSDs (I thought it was actually
> pretty important to use it on them until now).

Well I find

"On the other side, TRIM is usually overrated. Drive itself should keep 
good performance even without TRIM, either by using internal garbage 
collecting process or by some area reserved for optimal writes handling."

a very, very weak statement on the matter, cause it lacks any links to any 
evidence for the statement made. For that I meant to knew up to know is 
that wear leaveling of the SSD can be more effective the more space the SSD 
controller/firmware can use for wear leveling freely. Thus when I give 
space back to the SSD via fstrim it has more space for wear leveling which 
should lead to more evenly distributed write pattterns and more evenly 
distributed write accesses to flash cells and thus a longer life time. I do 
not see any other means on how the SSD drive can do that data has been 
freed again except for it being overwritten, then the old write location 
can be freed of course. But then BTRFS does COW and thus when I understand 
this correctly, the SSD wouldn´t even be told when a file is overwritten, 
cause actually it isn´t, but is written to a new location. Thus especially 
for BTRFS I see even more reasons to use fstrim.

I have no scientifical backing either, but at least I tried to think of an 
explaination that appears logical to me instead of just saying it is so 
without providing any explaination at all. Yes, I dislike bold statements 
without any backing at all. (If I overread something in the text, please 
hint me to it, but I did not see any explaination or link to support the 
statement.)

I use ecryptfs and I use fstrim occassionally with BTRFS and Ext4, but I 
do not use online discard.

Thanks,
--

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Gmane