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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux