18 Feb 2012 13:39
Re: brtfs on top of dmcrypt with SSD. No corruption iff write cache off?
Martin Steigerwald <Martin <at> lichtvoll.de>
2012-02-18 12:39:24 GMT
2012-02-18 12:39:24 GMT
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