9

I have a 128GB Somnambulist SSD. I know this brand is one of the worst. I measured the speed using GNOME Disk Utility, and it showed a read/write speed of 420/340.

After encrypting the SSD with Debian 12, the read speed, as measured by the GNOME Disk Utility, dropped to 13.5 MB/s!

Is this drop in speed normal, or is the issue likely related to the SSD itself?

Daniel
  • 341
  • 11
  • Is there any chance the disk supports OPAL? It's a pretty common feature in SSDs. `sedutil-cli --scan` should tell you. I'm not sure how normal distro's set up a PBA to unlock it these days. – davolfman Jun 19 '23 at 22:50

1 Answers1

12

If your CPU is old enough it may not support AES-NI instructions, so encryption/decryption will be slow.

grep -qw aes /proc/cpuinfo && echo Supported || echo Unsupported

Will tell you everything.

Artem S. Tashkinov
  • 26,392
  • 4
  • 33
  • 64
  • 3
    Intel Atom N270: **unsupported**. Thank you very much. – Daniel Jun 19 '23 at 15:12
  • 8
    @Daniel if you must use encryption, you could try your luck with another cipher, like serpent-xts - it might be slightly faster than the default aes-xts on this cpu (try `cryptsetup benchmark`, but also benchmark with real I/O). – frostschutz Jun 19 '23 at 16:10
  • 3
    @Daniel Hmmm, I tried this with an old version of Lubuntu earlier, where benchmark showed faster-than-aes speeds for serpent-xts (>20MB/s instead of >10MB/s); but in Debian 12 the benchmark seems to be about the same for all ciphers. Sorry, I rarely / never use this device anymore (MSI netbook with N270), only dusted it off the shelf today... it's 15 years old and was very low end even back then, so it's just that slow unfortunately – frostschutz Jun 19 '23 at 18:17
  • Thank you @frostschutz. I have formated it again with no encryption and BTRFS. It's now working faster, but still slower than before: GNOME Disk Utility measured read/write speed of 130/100 MB/s. It's a serious drop in performance. I found an old test of this SSD in GNOME Disk utility of 420/337. I will not use encryption anymore. – Daniel Jun 19 '23 at 19:11
  • @Daniel Btrfs wants to manage the low-level SSD directly so with Btrfs or ZFS creating a raw filesystem on disk without partitioning would be better. Or you can try F2FS, also raw without partitioning – phuclv Jun 19 '23 at 23:58
  • 6
    @Daniel You may want to try using something other than BTRFS here, I strongly suspect that you will see significantly better performance. BTRFS is _very_ write-heavy compared to XFS, ext4, or even F2FS, so performance limitations in the lower layers of the storage st6ackt end to have a much bigger impact for it. Also, if you really want encryption, try using `cryptsetup benchmark` to see what encryption modes perform best on your setup. You pretty much always want XTS for FDE usage, but but any of the XTS algorithms should be sufficient for your use case. – Austin Hemmelgarn Jun 20 '23 at 00:18
  • 2
    @Daniel, if you want to use encryption, you might try the [XTEA](https://en.wikipedia.org/wiki/XTEA) cipher (you may need to compile a custom kernel to get support for it). It sacrifices security for performance, but it's better than nothing. – Mark Jun 20 '23 at 02:27
  • 1
    @phuclv: BTRFS works perfectly fine in partitions, just make sure your partition is aligned to a multiple of 1MiB or something that's definitely at least as large as any block size the SSD firmware might care about. BTRFS *can* aggregate multiple block devices into one filesystem instead of doing that with LVM or software RAID (`md`), but even then I'm not sure it's better to mkfs on the raw `/dev/sdX` instead of `/dev/sdX1`. Anyway, with a single BTRFS per block device, I've never had any problems using BTRFS on partitions. – Peter Cordes Jun 20 '23 at 06:34
  • 1
    Another thing Atom N270 lacks is hardware CRC instructions: BTRFS checksums data and metadata. (https://ark.intel.com/content/www/us/en/ark/products/36331/intel-atom-processor-n270-512k-cache-1-60-ghz-533-mhz-fsb.html / Diamondville CPUs have Bonnell cores - https://en.wikichip.org/wiki/intel/microarchitectures/bonnell - this was early in-order-exec Atom, before Silvermont. It had SSSE3 `pshufb`, but the 128-bit XMM register version of it runs as 4 uops, so it stalls decode, running with 6 cycle throughput. Some SIMD code might still get some speedup, but not good w/ byte shuffles) – Peter Cordes Jun 20 '23 at 06:42
  • @PeterCordes I recall it was said somewhere that Btrfs and ZFS can send commands directly to the SSD to manage the states so it's better that way. But indeed the bottleneck here is the CPU's checksum and encryption so probably the OP should change to a different FS – phuclv Jun 20 '23 at 09:26
  • Hi, thank you all. I have moved back to ext4 and the speed is still 130/100. Probably the SSD is not that thing. – Daniel Jun 20 '23 at 14:09