Re: выравнивание раздела: кому верить, fdisk или parted?
Sergey Spiridonov <sena@s73.work> wrote:
> В Thu, 5 Dec 2019 17:38:02 +0300 (MSK)
> yuri.nefedov@gmail.com пишет:
> > Боюсь, что баг-репорт не поможет, хотя можете попробовать.
> Ну да, они скажут что виноват драйвер кернела, который
> неправильно понимает УСБ-Контроллер... Наверное надо куда-то в кернел
> писать?
Лучше в спортлото. Цифирка, которая в optimal_io - это к USB UASP относится.
К твоему диску - нет.
> Я согласен уже на всё, но какой брать отступ? Какие для этого есть
> правила???
Никакой.
> Например, если я правильно понял, fdisk отступил 2048 логических
> сектора по 512 байт. Это хорошо? Это нормально? Или лучше отступить
> 65536? Может ошибка контроллера - сообщать 65535 вместо 65536. Или это
> неправильная интерпретация стандарта, одни считают от 0, другие от 1?
> Или лучше достать диск, разбить на разделы и вставить обратно? А не
> будет ли при этом потом проблем с УСБ контроллером?
> Я потом раздел шифрую люксом, это как-то влияет?
Да, всё тормозит на шифровании.
> Спасибо за помощь. Блин, 2019 год, а в линуксе проблема разбить винт.
> Куда катится мир?
Нет проблем в 2019 году с винтами. Есть проблемы с теми, кто это пытается
делать не понимая.
Для начала пойми, что жесткий диск - это такой "черный ящик", которы только
сам знает как он работает. А то, что он рассказывает по интерфейсу - это
сказки. Причем эти сказки щедро сдобрены попытками обхода непродуманности
интерфейсов: 63 сектора - это кто-то всего 5 бит на количество секторов
оставил в районе IBM XT, обошли это увеличением количества головок. 4096
байт на сектор - это следующий предел в 2Tb (32 бита) на количество
секторов, обошли - увеличением длинны сектора.
Длинна сектора в 4096 - это вобще к NAND используемой в SSD. К обычным
дискам с шпинделями никаких отношение не имеет, т.к. про физический вид
дорожки не один производитель не скажет, ибо патенты.
Теперь, посмотрим в гуголь - на все запросы про 4k aligment находятся одни
новые толкования старых сказок про 63 сектора, etc. И "исследования" без
цифр и про windows всех категорий. Да, виндам оно надо - у них $MFT маркеры
в начале диска и пишут они туда ой как активно. Но опять-же, с обычным
rotational HDD - наплевать и размазать, потери времени на ре-позиционированние
головки с стабилизацией в РАЗЫ больше выгоды от того, сколько надо считать
и записать микрон данных с поверхности.
А если сюда прибавить так любимый метод "черепичной записи" (SMR) и его
вариацию SMR-DM с фирмварью пытающейся парсить NTFS на лету... То все
древние сказки про CHS/LBA отступы в 63/2048 секторов и прочие шаманства
становятся полным бредом, т.к. диску надо еще и соседние дорожки
перезаписывать.
Поэтому, для обычного HDD все эти сказки про скорости и выравнивания -
обычный маркетинговый fud. Для SSD по большей части тоже, т.к. контроллеры
умнеют, а все веселые картинки про "драматичесике изменения скорости" видны
только из далекого прошлого. А ведь в 3D-NAND уже размер блока 16K+2208 spare,
но что-то никто не бегает с align 16K и размером сектора в 16k вместо 4k.
Reply to: