Open ngrigoriev opened 7 months ago
My guess, without trying to reproduce it, is that it's part of the filesystem probe code. I'm not sure if there's really much that can be done about it.
To reproduce it, you will need an OPAL2 - capable device + cryptsetup 2.7.0+ (or latest git version if using 4K sectors). And you will need to encrypt a partition.
I think there may be two improvements to be made:
1 - add a flag to partprobe instructing it to avoid reading any data from any partition (e.g. strictly the partition table) 2 - if (I do not know if it is the case or not) fs probe code understand LUKS header, it may check for the new LUKS feature (as of 2.7.0) - support for hardware encryption. I think this metadata is written to the LUKS header. If hardware encryption is configured, then reading the range covered by LUKS is not going to work.
I am setting up a disk with 4K sector size (native) and hardware encryption (OPAL).
With hardware encryption, you end up with the sectors locked at the disk hardware level. They will not be readable at all until the locking range is unlocked. It means kernel errors, although parted seems to ignore them.
I can see with strace that partprobe attempts to read some sectors at odd location, including the sectors at the end of a partition. Maybe it is due to some alignment, not sure.
For example, I have a partition starting from the sector 601,344 ending at 488,378,111 (487,776,768 sectors). It has LUKS header. Type is LVM. partprobe /dev/nvme0n1 for some unknown reason is trying to read the LBA 488,378,111. Why? Since this range is locked, this causes an I/O error.