/sbin/fstrim: /home: FITRIM ioctl failed: Operation not supported
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 8 lines · Cristian Rodríguez
Hi:
I get the error message in $Subject if I try to use
/sbin/fstrimon all my filesystems BUT /boot which is the only one which is not encrypted.How am I supposed to "trim" dm-crypt/LUKS volumes on an SSD device ?
Thanks.
First, trim is a nicety, not a 100% requirement. The FITRIM ioctl was just introduced in 2.6.37 and it does NOT work in all environments. ie. I don't think LVM / mdraid are supported either. But they may just silently drop the trim commands in the block stack.
The main solution prior to 2.6.37 was wiper.sh from the hdparm package. But it to had known limitations similar to those above.
As to your real question
I suspect that is a question you need to take to lkml or one of its sub-mailing lists.
[email protected],
[email protected]
I monitor the ext4 one and have not seen any discussion related to trimming dm-crypt/LUKS protected volumes that I recall.
I also wonder if wiper.sh from hdparm would work with your filesystems. Trouble is a failure may cause major data loss. I have no idea of the odds, I'm just very nervous about unintentionally trimming the wrong sectors.
Mark Lord is the maintainer of hdparm. I've found him to be pretty responsive to questions about wiper.sh, so if you can't tell from the release notes, etc. I'd send him a email.
Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 10 lines · Greg Freemyer
Quoted 8 lines · Cristian Rodríguez
Hi:
I get the error message in $Subject if I try to use
/sbin/fstrimon all my filesystems BUT /boot which is the only one which is not encrypted.How am I supposed to "trim" dm-crypt/LUKS volumes on an SSD device ?
Thanks.
No NO NO! Big no to trimming encrypted filesystems! When you are discarding blocks, the subsequent read from those blocks are usually "well defined" and hence you are giving away useful information for attacker trying to decrypt your filesystem. And I do not think dm-crypt guys will ever allow this. wiper.sh might work, however you can as well give up on using encrypted filesystem.
Now, there might be some way around this to allow trimming encrypted volumes without serious security issue, but this is rather question for dm-crypt guys.
Thanks!
-Lukas
Quoted 34 lines
First, trim is a nicety, not a 100% requirement. The FITRIM ioctl was just introduced in 2.6.37 and it does NOT work in all environments. ie. I don't think LVM / mdraid are supported either. But they may just silently drop the trim commands in the block stack.
The main solution prior to 2.6.37 was
wiper.shfrom the hdparm package. But it to had known limitations similar to those above.As to your real question
I suspect that is a question you need to take to lkml or one of its sub-mailing lists.[email protected],
[email protected]I monitor the ext4 one and have not seen any discussion related to trimming dm-crypt/LUKS protected volumes that I recall.
I also wonder if
wiper.shfrom hdparm would work with your filesystems. Trouble is a failure may cause major data loss. I have no idea of the odds, I'm just very nervous about unintentionally trimming the wrong sectors.Mark Lord is the maintainer of hdparm. I've found him to be pretty responsive to questions about
wiper.sh, so if you can't tell from the release notes, etc. I'd send him a email.Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 4 lines · Lukas Czerner
Quoted 2 lines · Greg Freemyer
On Tue, Feb 22, 2011 at 6:09 PM, Cristian Rodríguez <[email protected]> wrote:
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Hi:
I get the error message in $Subject if I try to use
/sbin/fstrimon all my filesystems BUT /boot which is the only one which is not encrypted.How am I supposed to "trim" dm-crypt/LUKS volumes on an SSD device ?
Thanks.
Lukas, thanks for your answer.
Quoted 4 lines
No NO NO! Big no to trimming encrypted filesystems! When you are discarding blocks, the subsequent read from those blocks are usually "well defined" and hence you are giving away useful information for attacker trying to decrypt your filesystem.
I understand that there might be security issues, but so far, for this scenario the only kind of attacker from which I need to protect my desktop is from low-funded regular thieves that may break into my home office, unlikely that will get pass the volume password prompt ;-)
Quoted 3 lines
Now, there might be some way around this to allow trimming encrypted volumes without serious security issue, but this is rather question for dm-crypt guys.
Maybe making work the "discard" mount option ?
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 27 lines · Cristian Rodríguez
Quoted 4 lines · Lukas Czerner
Quoted 2 lines · Greg Freemyer
On Tue, Feb 22, 2011 at 6:09 PM, Cristian Rodríguez <[email protected]> wrote:
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Hi:
I get the error message in $Subject if I try to use
/sbin/fstrimon all my filesystems BUT /boot which is the only one which is not encrypted.How am I supposed to "trim" dm-crypt/LUKS volumes on an SSD device ?
Thanks.
Lukas, thanks for your answer.
Quoted 4 lines
No NO NO! Big no to trimming encrypted filesystems! When you are discarding blocks, the subsequent read from those blocks are usually "well defined" and hence you are giving away useful information for attacker trying to decrypt your filesystem.
I understand that there might be security issues, but so far, for this scenario the only kind of attacker from which I need to protect my desktop is from low-funded regular thieves that may break into my home office, unlikely that will get pass the volume password prompt ;-)
Quoted 6 lines
Quoted 3 lines
Now, there might be some way around this to allow trimming encrypted volumes without serious security issue, but this is rather question for dm-crypt guys.
Maybe making work the "discard" mount option ?
--
This is really a question for dm-crypt/block layer guys. Adding [email protected] into cc.
Quoted 4 lines
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 5 lines · Lukas Czerner
Quoted 5 lines
Quoted 3 lines
Now, there might be some way around this to allow trimming encrypted volumes without serious security issue, but this is rather question for dm-crypt guys.
Maybe making work the "discard" mount option ?
There were discussion about TRIM on dm-crypt mailing list several times.
one of it is here http://thread.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/4075/ )
Currently TRIM/discard is not intentionally supported on dm-crypt.
Security aspects are obvious (leaking of used blocks at least).
The decision cannot be done in kernel automatically, you can have different policies, in some situation TRIM of encryption device is not problem, in other it can be disaster.
So plan is to implement TRIM in dm-crypt but never enable it by default.
You will be able to enable it per-device using device-mapper message with explicit user request.
(we are using the same message mechanism for wiping/resuming key when freezing device).
In future this can be flag for LUKS2 metadata but current version of LUKS doesn't allow such extensions.
Milan