У меня есть накопитель Western Digital 4 ТБ (WD40PURZ). Похоже, что рекомендуемая процедура разбиения диска приводит к появлению предупреждения «Оптимальный размер передачи 33553920 байт, не кратного размеру физического блока (4096 байт)» от ядра Linux. Должен ли я беспокоиться об этом?
У меня есть аналогичный диск, WD20EFAX-68FB5N0, доступ к которому осуществляется через UAS. Я не уверен на 100%, но после прочтения ссылок ниже я думаю, что эта строка сама по себе не повод для беспокойства. Кажется, это на самом деле указывает на то, что используемое вами ядро имеет важное исправление.
Похоже, это вызвано тем, что накопитель неправильно сообщает оптимальный размер передачи 0xFFFF, который, если умножить его на 512 байт, составляет 3 355 3920 байт. Ядро Linux проверяет это значение на работоспособность и в этом случае делает вывод, что оно должно быть неправильным, поскольку оно не кратно размеру физического блока диска, равному 4096 байтам. Поэтому ядро игнорирует сообщаемый оптимальный размер передачи и сообщает, что, регистрируя указанную вами строку:
Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)
Возможно, когда вы запускаете lsblk -t
, OPT-IO
теперь сообщается как 0
.
# lsblk -t
NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME
sdb 0 4096 0 4096 512 1 mq-deadline 60 128 32M
├─sdb1 0 4096 0 4096 512 1 mq-deadline 60 128 32M
└─sdb2 0 4096 0 4096 512 1 mq-deadline 60 128 32M
До того, как ядро Linux внедрило эту проверку работоспособности, неправильный оптимальный размер передачи фактически приводил к тому, что инструменты разбиения на разделы выбирали неправильные начальные местоположения раздела, см. http://gparted-forum.surf4.info/viewtopic.php?id= 17839
В феврале/марте 2019 года была введена проверка работоспособности, а также она была перенесена на некоторые старые ядра:
Если вы создали разделы до этого времени, вы можете использовать fdisk -l
, чтобы узнать, делятся ли их начальные местоположения на 8 (секторов по 512 байт) или 4096 (байт). Обычно fdisk -l
совершенно ясно жалуется на то, что разделы не начинаются на границе физического сектора. См. Раздел не начинается на границе физического сектора?.