On Mon, Feb 06, 2017 at 11:15:59AM +0100, Ondrej Kozina wrote: > On 02/03/2017 05:42 PM, Nathanael D. Noblet wrote: > > > > Also what are the risks of enabling this? > > There's nice overview for it: > http://asalor.blogspot.cz/2011/08/trim-dm-crypt-problems.html > > In short (beside other facts covered in blog): > > A very simple analysis of encrypted block device with discard passdown > enabled (fstrim command on upper layer is allowed to hit block device > underneath the dm-crypt target) may expose presence of particular fs type. > It creates well visible patterns (interleaving chunks of zeroes with chunks > of random data) but no ciphertext is jeopardized in any way! > > Simply put with discard passdown enabled it'll be much harder to deny > _existence_ of encrypted fs on SSDs alone. > > The reasoning for the change is that most users expects theirs SSD to > operate in full performance (moreover, overall dm-crypt performance within > multi CPU systems was vastly improved with kernel 4.0: https://kernelnewbies.org/Linux_4.0#head-c0673746b8f925cd7013db3bf2a1ae1b76a18829) > and they experienced major performance hit after some time of use even > though they enabled fstrim.service & co. Most complains we heard were > exactly those above. Experienced admins are already aware of /etc/crypttab > and may revert the change very easily and existing storage setup will not be > affected. Admins can revert the change, but if a TRIM has already occurred, that can't be reversed without rewriting the affected sections of the drive. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
