Hi.
Just a few thoughts and questions on this:
1) Was it decided now, that TRIM will by default be blocked at dm-crypt level?
2) A solution that came up was to make blocking configurable via
module parameter. Wouldn't it be better to configure that as option in
the LUKS header and/or per device when setting up the dm-crypt- or
LUKS-mapping via crpytsetup?
The reason is that one might not want to set this globally for _all_
dm-crypt devices... e.g. swap might have not that tight
security-constraints (regarding deniability nad so on) as a pure data
partition... so one might want to chose that some for some dm-crypt
devices TRIM is passed on, while for others not.
3) Blocking/announcing TRIM at the dm-crypt block device to higher
level things (especially filesystems).
I assume block devices somehow announce their capabilities (in that
case) trim to userspace and the kernel, right?
I further assume that also dm-crypt devices (/dev/mapper/sda1 or so)
pass this somehow on.. in both directions,.. up (to kernel/userspace)
and down (to kernel, e.g. LVM or RAID sitting below), right? I mean a
filesystem like btrfs/ext4 must somehow know whether the disk is an
SSD or not, and in addition whether it supports TRIM.
Right so far?
a) How far is this already implemented in the meantime, and in
starting with which kernel version? I read at some place that dm
itself would not yet support it?
b) If we consider that we probably block TRIM,... is this properly
propagated to things on top (filesystems, userspace stuff like hdparm).
I mean just silently discarding TRIM could lead to problems if a fs
like btrfs thinks that TRIM is suppored and behaves specially because
of this,... but it never reaches the device.
Thanks,
Chris.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
