All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thorsten Glaser <tg@evolvis.org>
To: cryptsetup@lists.linux.dev
Subject: 4K sector size, cryptswap, with/-out dm-integrity?
Date: Fri, 10 Jul 2026 19:14:55 +0200 (CEST)	[thread overview]
Message-ID: <91244f91-7fdd-780f-8860-dfa7e784b7dc@evolvis.org> (raw)

Hi,

I’ve been looking a bit at how 4K sector sizes are passed
through the stack today, and I’m wondering a bit about
things the docs don’t have sufficiently deep details for.

AIUI, and please correct me if I’m wrong anywhere:

First, the easy(?) cases:

- HDD with 512 bytes underlying sector size ⇒ 4K sectors never ok
- SSD with 512 bytes logical sector size and no 4K listed in
  the “smartctl -c /dev/nvme0n1” / “nvme id-ns -H /dev/nvme0n1”
  output ⇒ 4K sectors likely not ok?

- HDD/SSD with 4K logical sectors ⇒ 4K sectors ok

The documentation also says that this should be:

- dm-integrity device with --sector-size 4096 in journalled mode ⇒ ok
  - does this even differ between underlying 512/512, 512/4K, 4K/4K devices?
- same but in D (direct) mode ⇒ not ok unless underlying device is
  - 4K/4K?
  - 512/4K or 4K/4K (see below)?
- same but in B (bitmap) mode ⇒ ?
- same but in I (inline) mode ⇒ only ok if the underlying device matches?
- R (recovery) mode is special anyway

Then, there’s this one:

- HDD with 512b logical and 4K physical sectors according to
  “hdparm -I”/“smartctl -i” ⇒ that ok?

And the thing I’ve really been wondering about is:

at the moment, I use encrypted swap like this (crypttab):

# <target name> <source device>         <key file>      <options>
cswp1           /dev/………                /dev/urandom    discard,cipher=aes-xts-plain64,size=512,plain,swap

Is it possible to add “,sector-size=4096” to that line and
will it help (encrypting 4K in one go is faster than eight
times 512b after all)? Does the kernel swapping subsystem
work with that? (On amd64, so my page size is 4096, though
since 4K pages on 512b devices works, 16K/64K pages on 4K
devices will likely also work for things like MIPS, ARM…)

If so, under the same circumstances as above? (Either 4K logical
device (which I seem to not have) or 4K integritysetup with journal
(also on 512/4K or 512/512 devices?) or MAYBE 512/4K devices?)

I’ve been putting integritysetup with 4K sectors and journal
under my RAID-1+LUKS recently already anyway, even if performance
is… lacking. But I should stick to J (journal) mode with this, no?

Thanks,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
	-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

             reply	other threads:[~2026-07-10 17:22 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-10 17:14 Thorsten Glaser [this message]
2026-07-10 18:16 ` 4K sector size, cryptswap, with/-out dm-integrity? Thorsten Glaser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=91244f91-7fdd-780f-8860-dfa7e784b7dc@evolvis.org \
    --to=tg@evolvis.org \
    --cc=cryptsetup@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.