Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #188648 > unrolled thread

how to enable trim for an external encrypted SSD?

Back to article view | Back to linux.debian.user

Contents

  how to enable trim for an external encrypted SSD? Joerg Desch <news@jdesch.de> - 2017-11-06 13:10 +0100
    Re: how to enable trim for an external encrypted SSD? Christian Seiler <christian@iwakd.de> - 2017-11-06 14:30 +0100
      Re: how to enable trim for an external encrypted SSD? "Alexander V. Makartsev" <avbetev@gmail.com> - 2017-11-06 21:10 +0100
        Re: how to enable trim for an external encrypted SSD? Michael Stone <mstone@debian.org> - 2017-11-06 21:50 +0100
          Re: how to enable trim for an external encrypted SSD? "Alexander V. Makartsev" <avbetev@gmail.com> - 2017-11-06 22:30 +0100
            Re: how to enable trim for an external encrypted SSD? Michael Stone <mstone@debian.org> - 2017-11-06 23:10 +0100
              Re: how to enable trim for an external encrypted SSD? "Alexander V. Makartsev" <avbetev@gmail.com> - 2017-11-07 00:20 +0100
                Re: ow to enable trim for an external encrypted SSD? dekkzz78@gmail.com - 2017-11-07 13:40 +0100
            Re: how to enable trim for an external encrypted SSD? Henrique de Moraes Holschuh <hmh@debian.org> - 2017-11-07 02:10 +0100
        Re: how to enable trim for an external encrypted SSD? Joerg Desch <news@jdesch.de> - 2017-11-07 08:20 +0100
      Re: how to enable trim for an external encrypted SSD? Joerg Desch <news@jdesch.de> - 2017-11-07 08:10 +0100
      Re: how to enable trim for an external encrypted SSD? Joerg Desch <news@jdesch.de> - 2017-11-11 14:10 +0100
        Re: how to enable trim for an external encrypted SSD? Christian Seiler <christian@iwakd.de> - 2017-11-11 14:20 +0100
          Re: how to enable trim for an external encrypted SSD? Joerg Desch <news@jdesch.de> - 2017-11-11 14:40 +0100
            Re: how to enable trim for an external encrypted SSD? Christian Seiler <christian@iwakd.de> - 2017-11-11 15:30 +0100
              Re: how to enable trim for an external encrypted SSD? Joerg Desch <news@jdesch.de> - 2017-11-11 16:50 +0100
                Re: how to enable trim for an external encrypted SSD? Stefan Monnier <monnier@iro.umontreal.ca> - 2017-11-16 04:10 +0100
                  Re: how to enable trim for an external encrypted SSD? Joerg Desch <news@jdesch.de> - 2017-11-21 18:40 +0100
      Re: how to enable trim for an external encrypted SSD? Christian Seiler <christian@iwakd.de> - 2017-12-18 13:20 +0100

#188648 — how to enable trim for an external encrypted SSD?

Normally I would enable TRIM support in the /etc/fstab or the /etc/
crypttab by add the discard option.

Now I have bought a SanDisk Extreme Portable SSD. My goal is to add a LUKS 
encrypted partition without an explicit fstab entry. I've done this with 
some USB thumbdrives before, but not with TRIM support. The drvie should 
be plugged into any Linux device without the need to change the 
configuration.

What is the correct way to add TRIM support to an external SSD with LUKS 
encrypted partition?

[toc] | [next] | [standalone]

#188649

Am 2017-11-06 13:09, schrieb Joerg Desch:
> Now I have bought a SanDisk Extreme Portable SSD. My goal is to add a 
> LUKS
> encrypted partition without an explicit fstab entry. I've done this 
> with
> some USB thumbdrives before, but not with TRIM support. The drvie 
> should
> be plugged into any Linux device without the need to change the
> configuration.
> 
> What is the correct way to add TRIM support to an external SSD with 
> LUKS
> encrypted partition?

I don't what you want is possible. When you plug in an external drive
(that is _not_ in /etc/fstab etc.) the process of how it gets mounted
is different:

  - For configured drives (/etc/fstab etc.) the init system (e.g.
    systemd, but also initscripts when you are using sysvinit) will
    read /etc/crypttab and /etc/fstab and apply those options to
    the LUKS container and the filesystem.

  - For non-configured drives the 'udisks' helper program will
    enable the user to decrypt & mount those devices.

Now, at least the ext4 filesystem allows you to set default mount
options, such as 'discard':

    tune2fs -o +discard /dev/external_disk_device

btrfs on the other hand tries to auto-detect SSDs and enable
discard automatically if on an SSD - but I have no idea whether that
works under LUKS or not.

But all that doesn't really help you if the underlying LUKS container
isn't opened with the discard option set. And as far as I know there
is no possibility of tagging a LUKS container with that option, you
must always supply that option to the cryptsetup command (which is
done implicitly via /etc/crypttab).

And while you might be able to reconfigure udisks to pass the discard
option to cryptsetup (though I'm also doubtful about that), that
configuration would have to happen on each individual computer, and
can't be put onto the external drive.

In summary:

  - If your filesystem is not encrypted, btrfs out of the box, and
    ext4 with the proper option set, should make it possible to
    automatically enable mounting with the correct option.

  - But I don't know of any method to tag a LUKS container so that it
    is opened with TRIM support by default.

Hence I don't think what you want is possible with the current state
of affairs, unfortunately. Sorry.

You could ask the LUKS developers to include an additional flag in
their headers that allows you to specify that this volume should be
opened with discards allowed by default - to maybe solve this in the
very long term. No idea how amenable they'd be towards that though,
as they do discourage the usage of TRIM in LUKS because it weakens
possible security guarantees somewhat.

Regards,
Christian

[toc] | [prev] | [next] | [standalone]

#188655

[Multipart message — attachments visible in raw view] — view raw

On 06.11.2017 18:28, Christian Seiler wrote:
>
> You could ask the LUKS developers to include an additional flag in
> their headers that allows you to specify that this volume should be
> opened with discards allowed by default - to maybe solve this in the
> very long term. No idea how amenable they'd be towards that though,
> as they do discourage the usage of TRIM in LUKS because it weakens
> possible security guarantees somewhat.
>
> Regards,
> Christian
>
Thank you for an insightful answer.
Now I wonder, why would anyone want to use TRIM feature on a portable
SSD, especially on an encrypted one?
Isn't this feature only increases drive wear, offering next to nothing
as a benefit in return?
I don't use TRIM feature on my systems because of that, and hope for a
firmware of modern SSD will manage everything automatically. Am I wrong?

-- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀ 

[toc] | [prev] | [next] | [standalone]

#188658

On Tue, Nov 07, 2017 at 01:00:54AM +0500, Alexander V. Makartsev wrote:
>Now I wonder, why would anyone want to use TRIM feature on a portable SSD,
>especially on an encrypted one?
>Isn't this feature only increases drive wear, offering next to nothing as a
>benefit in return?
>I don't use TRIM feature on my systems because of that, and hope for a firmware
>of modern SSD will manage everything automatically. Am I wrong?

TRIM should reduce, not increase, drive wear. (Since the drive knows 
that a particular block is unusued, it can write directly instead 
of having to read and rewrite an entire erase group.) It should also 
increase performance by increasing the free pool on the drive and reduce 
the garbage collection pressure. The magnitude of any benefits depends 
heavily on how the drive is used and how the firmware implements its 
writing and garbage collection routines.

A possible negative is that some drives have bugs in their TRIM 
implementation (known bad drives are blacklisted). Also, enabling TRIM 
at the filesystem level can reduce performance depending on the drive's 
implementation and the read/write patterns on the filesystem. (Issuing 
large numbers of small TRIM operations can negatively affect 
performance.) That disadvantage can be avoided by running fstrim in 
batch rather than having the filesystem TRIM as files are deleted.

Mike Stone

[toc] | [prev] | [next] | [standalone]

#188660

[Multipart message — attachments visible in raw view] — view raw

On 07.11.2017 01:43, Michael Stone wrote:
> On Tue, Nov 07, 2017 at 01:00:54AM +0500, Alexander V. Makartsev wrote:
>> Now I wonder, why would anyone want to use TRIM feature on a portable
>> SSD,
>> especially on an encrypted one?
>> Isn't this feature only increases drive wear, offering next to
>> nothing as a
>> benefit in return?
>> I don't use TRIM feature on my systems because of that, and hope for
>> a firmware
>> of modern SSD will manage everything automatically. Am I wrong?
>
> TRIM should reduce, not increase, drive wear. (Since the drive knows
> that a particular block is unusued, it can write directly instead of
> having to read and rewrite an entire erase group.)
As I know SSDs are different in a way HDDs write their data. HDDs write
directly to the free block and are done. SSDs on the other hand will
have to erase free block first to get it ready for writing and then
write to it. This is because how NAND work. It's even worse, if a
destination block has some data on it already and there is some data
needs to be written onto it, then SSD will copy data already written,
then it will fully erase destination block, then it will concatenate
copied data with data to be written and finally will write merged data
to the block.
TRIM will erase blocks marked as deleted beforehand even if they are not
needed for writing right now. This overhead is the reason that causes
increased drive wear and decrease it's lifespan.

I do agree, that using fstune manually once in say half a year on a non
busy SSD could improve writing performance for some time, but using
discard or equivalent permanently in fstab is hardly worth it.

-- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀ 

[toc] | [prev] | [next] | [standalone]

#188661

On Tue, Nov 07, 2017 at 02:20:56AM +0500, Alexander V. Makartsev wrote:
>As I know SSDs are different in a way HDDs write their data. HDDs write
>directly to the free block and are done. SSDs on the other hand will have to
>erase free block first to get it ready for writing and then write to it. This
>is because how NAND work. It's even worse, if a destination block has some data
>on it already and there is some data needs to be written onto it, then SSD will
>copy data already written, then it will fully erase destination block, then it
>will concatenate copied data with data to be written and finally will write
>merged data to the block.

This is mostly correct. The erasing is done in "erase block" size units 
(much larger than disk blocks), while writing is done in "pages", 
usually with hundreds of pages per erase block. So a 4kbyte write might 
trigger a multi-megabyte erase if there aren't erased pages available 
for writing. If an erase block has been partially written, a write can 
go to an unwritten page without any additional steps. In practice, 
most drive writes go immediately to already-erased blocks, with the garbage 
collector erasing blocks while the drive is idle (rather than actually 
reading, erasing, and writing for every write). The drive then keeps 
track of which physical address is associated with which logical 
address--that relationship changes as blocks are written and rewritten, 
and it is not the case that the data on the drive is physically ordered 
the same way it appears logically.

>TRIM will erase blocks marked as deleted beforehand even if they are not needed
>for writing right now. This overhead is the reason that causes increased drive
>wear and decrease it's lifespan.

No, TRIM does not cause extra erases that wear out a drive. If you don't 
TRIM blocks and mark them as unused, the garbage collector will still 
erase blocks it doesn't need yet in order to have pages available for 
future writes. (Either after the garbage collector decides to launch a 
read & rewrite cycle to consolidate free space, or when all the pages
in the erase block have been rewritten to a new erase block and the old 
erase block is known to be empty) The only differences introduced by 
using TRIM is that the drive can skip the possible read & rewrite step, 
and the drive can increase the free pool so more new pages can be 
written before a garbage collection is forced.

Mike Stone

[toc] | [prev] | [next] | [standalone]

#188662

[Multipart message — attachments visible in raw view] — view raw

On 07.11.2017 03:01, Michael Stone wrote:
> On Tue, Nov 07, 2017 at 02:20:56AM +0500, Alexander V. Makartsev wrote:
>> As I know SSDs are different in a way HDDs write their data. HDDs write
>> directly to the free block and are done. SSDs on the other hand will
>> have to
>> erase free block first to get it ready for writing and then write to
>> it. This
>> is because how NAND work. It's even worse, if a destination block has
>> some data
>> on it already and there is some data needs to be written onto it,
>> then SSD will
>> copy data already written, then it will fully erase destination
>> block, then it
>> will concatenate copied data with data to be written and finally will
>> write
>> merged data to the block.
>
> This is mostly correct. The erasing is done in "erase block" size
> units (much larger than disk blocks), while writing is done in
> "pages", usually with hundreds of pages per erase block. So a 4kbyte
> write might trigger a multi-megabyte erase if there aren't erased
> pages available for writing. If an erase block has been partially
> written, a write can go to an unwritten page without any additional
> steps. In practice, most drive writes go immediately to already-erased
> blocks, with the garbage collector erasing blocks while the drive is
> idle (rather than actually reading, erasing, and writing for every
> write). The drive then keeps track of which physical address is
> associated with which logical address--that relationship changes as
> blocks are written and rewritten, and it is not the case that the data
> on the drive is physically ordered the same way it appears logically.
>
>> TRIM will erase blocks marked as deleted beforehand even if they are
>> not needed
>> for writing right now. This overhead is the reason that causes
>> increased drive
>> wear and decrease it's lifespan.
>
> No, TRIM does not cause extra erases that wear out a drive. If you
> don't TRIM blocks and mark them as unused, the garbage collector will
> still erase blocks it doesn't need yet in order to have pages
> available for future writes. (Either after the garbage collector
> decides to launch a read & rewrite cycle to consolidate free space, or
> when all the pages
> in the erase block have been rewritten to a new erase block and the
> old erase block is known to be empty) The only differences introduced
> by using TRIM is that the drive can skip the possible read & rewrite
> step, and the drive can increase the free pool so more new pages can
> be written before a garbage collection is forced. 
I still think there are scenarios where NAND ICs will suffer extra
writes, when TRIM is constantly used.
Also, can you explain what logic is behind this quote from "man 8 fstrim":
    "Running fstrim frequently, or even using mount -o discard, might
negatively
      affect  the  lifetime  of  poor-quality  SSD devices."

I think I will find my answers in this huge article on wikipedia when I
wade through it eventually, should be quite interesting read:
https://en.wikipedia.org/wiki/Write_amplification

-- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀ 

[toc] | [prev] | [next] | [standalone]

#188682 — Re: ow to enable trim for an external encrypted SSD?

[Multipart message — attachments visible in raw view] — view raw

On 11/07, Alexander V. Makartsev wrote:
>On 07.11.2017 03:01, Michael Stone wrote:
>> On Tue, Nov 07, 2017 at 02:20:56AM +0500, Alexander V. Makartsev wrote:
>>> As I know SSDs are different in a way HDDs write their data. HDDs write
>>> directly to the free block and are done. SSDs on the other hand will
>>> have to
>>> erase free block first to get it ready for writing and then write to
>>> it. This
>>> is because how NAND work. It's even worse, if a destination block has
>>> some data
>>> on it already and there is some data needs to be written onto it,
>>> then SSD will
>>> copy data already written, then it will fully erase destination
>>> block, then it
>>> will concatenate copied data with data to be written and finally will
>>> write
>>> merged data to the block.
>>
>> This is mostly correct. The erasing is done in "erase block" size
>> units (much larger than disk blocks), while writing is done in
>> "pages", usually with hundreds of pages per erase block. So a 4kbyte
>> write might trigger a multi-megabyte erase if there aren't erased
>> pages available for writing. If an erase block has been partially
>> written, a write can go to an unwritten page without any additional
>> steps. In practice, most drive writes go immediately to already-erased
>> blocks, with the garbage collector erasing blocks while the drive is
>> idle (rather than actually reading, erasing, and writing for every
>> write). The drive then keeps track of which physical address is
>> associated with which logical address--that relationship changes as
>> blocks are written and rewritten, and it is not the case that the data
>> on the drive is physically ordered the same way it appears logically.
>>
>>> TRIM will erase blocks marked as deleted beforehand even if they are
>>> not needed
>>> for writing right now. This overhead is the reason that causes
>>> increased drive
>>> wear and decrease it's lifespan.
>>
>> No, TRIM does not cause extra erases that wear out a drive. If you
>> don't TRIM blocks and mark them as unused, the garbage collector will
>> still erase blocks it doesn't need yet in order to have pages
>> available for future writes. (Either after the garbage collector
>> decides to launch a read & rewrite cycle to consolidate free space, or
>> when all the pages
>> in the erase block have been rewritten to a new erase block and the
>> old erase block is known to be empty) The only differences introduced
>> by using TRIM is that the drive can skip the possible read & rewrite
>> step, and the drive can increase the free pool so more new pages can
>> be written before a garbage collection is forced.
>I still think there are scenarios where NAND ICs will suffer extra
>writes, when TRIM is constantly used.
>Also, can you explain what logic is behind this quote from "man 8 fstrim":
>    "Running fstrim frequently, or even using mount -o discard, might
>negatively
>      affect  the  lifetime  of  poor-quality  SSD devices."

Poor quality FLASH RAM has lower MTBF, in some cases very much lower and given the 
NAND cluster failure mechanism death comes quickly.


>I think I will find my answers in this huge article on wikipedia when I
>wade through it eventually, should be quite interesting read:
>https://en.wikipedia.org/wiki/Write_amplification
>
>-- 
>With kindest regards, Alexander.
>
>⢀⣴⠾⠻⢶⣦⠀
>⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
>⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
>⠈⠳⣄⠀⠀⠀⠀
>

-- 
regards.....


Jabber IM:dekkzz78@jabber.hot-chilli.net

[toc] | [prev] | [next] | [standalone]

#188666

On Tue, 07 Nov 2017, Alexander V. Makartsev wrote:
> TRIM will erase blocks marked as deleted beforehand even if they are not

Not on any SSD that is not an utter piece of trash.

TRIM marks pages as unused for the garbage collector, and that's it.  On
SSDs that return all-zeroes for TRIMMed sectors, it likely also flushes
the unused-blocks journal to FLASH for security reasons.

It saves on FLASH wear because the SSD will *not* copy unused data
elsewhere in order to free up an entire erase block.

The garbage collector only runs in the background, unless the SSD is out
of free pages (which should *never* happen on any non-joke SSD, due to
enforced overprovisioned space).

-- 
  Henrique Holschuh

[toc] | [prev] | [next] | [standalone]

#188670

Am Tue, 07 Nov 2017 01:00:54 +0500 schrieb Alexander V. Makartsev:

> I don't use TRIM feature on my systems because of that, and hope for a
> firmware of modern SSD will manage everything automatically. Am I wrong?

I've used a ext4 formatted, unencrypted (!) 64GB SanDisk Extreme USB 3.0 
thumbdrive together with Unison. I sync a collection of documentation, 
some application configurations and a bunch of git repositories to it. 
The sync was done 4-5 days a week. The amount of changes was less than 
5MB a day.

IMO SanDisk is a trustful company with products of high quality. But the 
thumbdrive has not even lasted a year!

By the way... hdparm reports that the thumbdrive supports TRIM, but I was 
never able to use it!

So much for the topic "the firmware will do that". ;-)

[toc] | [prev] | [next] | [standalone]

#188669

Am Mon, 06 Nov 2017 14:28:32 +0100 schrieb Christian Seiler:

> But all that doesn't really help you if the underlying LUKS container
> isn't opened with the discard option set. And as far as I know there is
> no possibility of tagging a LUKS container with that option, you must
> always supply that option to the cryptsetup command (which is done
> implicitly via /etc/crypttab).

Thanks for your detailed and extensive answer. That's exactly the answer 
I was afraid of. ;-)

So I will add an entry to the /etc/crypttab and hope that fstrim will do 
it's job. All system without a modified crypttab should mount the device 
but fstrim will fail. I think I can live with that solution.


> You could ask the LUKS developers to include an additional flag in their
> headers that allows you to specify that this volume should be opened
> with discards allowed by default

That is a good idea. I think I will write an ticket for that.

Thanks again.

[toc] | [prev] | [next] | [standalone]

#188877

Am Mon, 06 Nov 2017 14:28:32 +0100 schrieb Christian Seiler:

> I don't what you want is possible. When you plug in an external drive
> (that is _not_ in /etc/fstab etc.) the process of how it gets mounted is
> different:
...
>     tune2fs -o +discard /dev/external_disk_device

My drive has arrived and even a ext4 without LUKS fails to (fs)trim the 
mount! Any idea why?

~~~~
$ sudo hdparm -I /dev/sdg1
...
	   *	Data Set Management TRIM supported (limit 8 blocks)
	   *	Deterministic read data after TRIM
$ sudo fstrim /media/jd/TEST
fstrim: /media/jd/TEST: Verwerfungsvorgang wird nicht unterstützt.
~~~~

[toc] | [prev] | [next] | [standalone]

#188878

On 11/11/2017 02:05 PM, Joerg Desch wrote:
> Am Mon, 06 Nov 2017 14:28:32 +0100 schrieb Christian Seiler:
> 
>> I don't what you want is possible. When you plug in an external drive
>> (that is _not_ in /etc/fstab etc.) the process of how it gets mounted is
>> different:
> ...
>>     tune2fs -o +discard /dev/external_disk_device
> 
> My drive has arrived and even a ext4 without LUKS fails to (fs)trim the 
> mount! Any idea why?
> 
> ~~~~
> $ sudo hdparm -I /dev/sdg1
> ...
> 	   *	Data Set Management TRIM supported (limit 8 blocks)
> 	   *	Deterministic read data after TRIM
> $ sudo fstrim /media/jd/TEST
> fstrim: /media/jd/TEST: Verwerfungsvorgang wird nicht unterstützt.
> ~~~~

Maybe the external controller (or at least the driver for the external
controller) that interfaces the SSD with USB (or whatever you're using
to connect it externally to your system) doesn't understand TRIM
properly?

Also, did you mount the device with -o discard or set that option with
tune2fs (_before_ mounting it)?

What does the command

findmnt | grep /media/jd/TEST

say in terms of active filesystem options?

Regards,
Christian

[toc] | [prev] | [next] | [standalone]

#188879

Am Sat, 11 Nov 2017 14:13:12 +0100 schrieb Christian Seiler:

> Also, did you mount the device with -o discard or set that option with
> tune2fs (_before_ mounting it)?

No, not now. I want to use fstrim in favour to the discard option. But 
I've tested it with an Arch Linux installation with a more fresh kernel. 
There both vairante (fstrim and discard-option in fstab) fails too. In 
case of the discard option, the error is written to the logs.

> What does the command
> findmnt | grep /media/jd/TEST

$ findmnt | grep /media/jd/TEST
├─/media/jd/TEST                      /dev/sdg1          ext4            
rw,nosuid,nodev,relatime,data=ordered

$ sudo lsblk -D
[sudo] password for jd: 
NAME   DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda           0      512B       2G         0
├─sda1        0      512B       2G         0
└─sda2        0      512B       2G         0
sdb           0        0B       0B         0
sdg           0        0B       0B         0
└─sdg1        0        0B       0B         0


In this case, sda is a internal SSD (Samsung EVO) with working TRIM and 
sdb is a HDD.

[toc] | [prev] | [next] | [standalone]

#188881

On 11/11/2017 02:31 PM, Joerg Desch wrote:
> Am Sat, 11 Nov 2017 14:13:12 +0100 schrieb Christian Seiler:
> 
>> Also, did you mount the device with -o discard or set that option with
>> tune2fs (_before_ mounting it)?
> 
> No, not now. I want to use fstrim in favour to the discard option. But 
> I've tested it with an Arch Linux installation with a more fresh kernel. 
> There both vairante (fstrim and discard-option in fstab) fails too. In 
> case of the discard option, the error is written to the logs.
> 
>> What does the command
>> findmnt | grep /media/jd/TEST
> 
> $ findmnt | grep /media/jd/TEST
> ├─/media/jd/TEST                      /dev/sdg1          ext4            
> rw,nosuid,nodev,relatime,data=ordered
> 
> $ sudo lsblk -D
> [sudo] password for jd: 
> NAME   DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
> sda           0      512B       2G         0
> ├─sda1        0      512B       2G         0
> └─sda2        0      512B       2G         0
> sdb           0        0B       0B         0
> sdg           0        0B       0B         0
> └─sdg1        0        0B       0B         0
> 
> 
> In this case, sda is a internal SSD (Samsung EVO) with working TRIM and 
> sdb is a HDD.

Well, then it appears that the chip (or the kernel driver for it) doesn't
support passing through the TRIM command to the underyling SSD.

If it's the kernel driver there's a chance that'll be fixed in a future
kernel version.

If it's the the chip itself you're stuck without TRIM on the external
SSD.

Unfortunately I can't say much more about that, I've never had an
external SSD.

Regards,
Christian

[toc] | [prev] | [next] | [standalone]

#188884

Am 11.11.17 15:27, schrieb Christian Seiler:

>If it's the kernel driver there's a chance that'll be fixed in a future
>kernel version.

Hmm... Arch Linux (that I tried) comes with a recent kernel and this still
 not work.


>Unfortunately I can't say much more about that, I've never had an
>external SSD.

I had the same situation with my Sandisc Exreme thumb drive before! Here
 heparin reports TRIM too, and fstrim failed too. At that time I thought
 that the problem is the thumb drive controller. A thumb drive is no SSD. As
 a result of the missing TRIM, the drive shows IO errors after just 1 year
 of usage.

That could become an expensive hobby. :-/

[toc] | [prev] | [next] | [standalone]

#189018

> I had the same situation with my Sandisc Exreme thumb drive before! Here
> heparin reports TRIM too, and fstrim failed too. At that time I thought
> that the problem is the thumb drive controller.

hdparm's report mostly comes directly from the drive within the
enclosure.  So all it says is that the drive within the enclosure
understands TRIM, but in many cases, the USB<->SATA adapter used in the
enclosure to talk to the disk only understands a subset of the SATA
commands.

You might ask the USB driver people if Linux's usb_storage
driver supports TRIM, if not, then there's a chance that the USB<->SATA
adapter still supports it, but I wouldn't hold my breath.

> As a result of the missing TRIM, the drive shows IO errors after just
> 1 year of usage.

I highly doubt that TRIM would help.  IOW, it's just a gut feeling you
have, but I strongly doubt you have concrete data that can show it might
be related to the presence/absence of TRIM-support.


        Stefan

[toc] | [prev] | [next] | [standalone]

#189164

Am Wed, 15 Nov 2017 22:00:54 -0500 schrieb Stefan Monnier:

> I highly doubt that TRIM would help.  IOW, it's just a gut feeling you
> have, but I strongly doubt you have concrete data that can show it might
> be related to the presence/absence of TRIM-support.

May be you are right. I hope so... ;-)

[toc] | [prev] | [next] | [standalone]

#189968

Hi again,

A quick follow-up, because cryptsetup 2.0.0 was recently released:

On 11/06/2017 02:28 PM, Christian Seiler wrote:
> And while you might be able to reconfigure udisks to pass the discard
> option to cryptsetup (though I'm also doubtful about that), that
> configuration would have to happen on each individual computer, and
> can't be put onto the external drive.

The new LUKS2 header format (requires cryptsetup 2.0.0) does support
this, the release announcement specifically mentions discards as a
feature option:

Quoting
<http://www.saout.de/pipermail/dm-crypt/2017-December/005771.html>:

  * Persistent flags
    The activation flags (like allow-discards) can be stored in
    metadata and used automatically by all later activations (even
    without using crypttab).

    To store activation flags permanently, use activation command
    with required flags and add --persistent option.

    For example, to mark device to always activate with TRIM
    enabled, use (for LUKS2 type):

     $ cryptsetup open <device> <name> --allow-discards --persistent

    You can check persistent flags in dump command output:

    $ cryptsetup luksDump <device>

Doesn't help you directly because of the problems you've described
with your USB adapter not forwarding TRIM commands properly, and
this feature will not be part of Debian before the release of
Debian 10/Buster (I hope at least ;-)), but I still wanted to
mention this in case anyone stumbles over this thread in the
mailing list archives.

Regards,
Christian

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web