Re: выравнивание раздела: кому верить, fdisk или parted?
On Tue, 10 Dec 2019 17:19:01 +0300
"Andrey Jr. Melnikov" <temnota.am@gmail.com> wrote:
> Sergey Spiridonov <sena@s73.work> wrote:
> > В Thu, 5 Dec 2019 17:38:02 +0300 (MSK)
> > yuri.nefedov@gmail.com пишет:
>
> > > Боюсь, что баг-репорт не поможет, хотя можете попробовать.
>
> > Ну да, они скажут что виноват драйвер кернела, который
> > неправильно понимает УСБ-Контроллер... Наверное надо куда-то в
> > кернел писать?
>
> Лучше в спортлото. Цифирка, которая в optimal_io - это к USB UASP
> относится. К твоему диску - нет.
Не понял тебя. В соответствующий драйвер можно USB UASP внести
изменение, и он будет поправлять optimal_io, в зависимости от усб
идентификатора, то есть возвращать либо 0 либо 33554432, вместо
33553920, как сейчас.
> > Я согласен уже на всё, но какой брать отступ? Какие для этого есть
> > правила???
>
> Никакой.
В смысле 0?
> > Я потом раздел шифрую люксом, это как-то влияет?
> Да, всё тормозит на шифровании.
Я читал что шифрование само по себе не должно добавлять много тормозов,
если ЦПУ поддерживает аппаратное ускорение AES. По крайней мере, так
пишут собаководы [1]. И это для SSD! Для шпинделя должно быть вообще
незаметно, ведь поток данных в разы меньше. Сам проверял это записывая
большой файл на вышеупомянутую зашифрованную шпиндельную Тошибу.
Скорость записи в 260МБ/с меня вполне устроила. При записи тучи мелких
файлов скорость записи падает да 10-20МБ/с, но можно ли винить в этом
шифрование, я пока не знаю, пока возможности сравнить нет.
https://www.phoronix.com/scan.php?page=article&item=2019-linux-encrypt&num=1
Впрочем даже если производительность винта упадёт в два раза, я это
переживу. Проблема в том что у меня проблема куда серьёзней (см. ниже)
> > Спасибо за помощь. Блин, 2019 год, а в линуксе проблема разбить
> > винт. Куда катится мир?
>
> Нет проблем в 2019 году с винтами. Есть проблемы с теми, кто это
> пытается делать не понимая.
Ну ОК, будем считать что я не понимаю. В конце концов это недалеко от
правды.
...
> Поэтому, для обычного HDD все эти сказки про скорости и выравнивания -
> обычный маркетинговый fud. Для SSD по большей части тоже, т.к.
> контроллеры умнеют, а все веселые картинки про "драматичесике
> изменения скорости" видны только из далекого прошлого. А ведь в
> 3D-NAND уже размер блока 16K+2208 spare, но что-то никто не бегает с
> align 16K и размером сектора в 16k вместо 4k.
То есть по-твоему выравнивание вообще не играют значения, если я
правильно понял. ОК, спасибо за совет.
Но даже если выравнивание значения не играет, то всё равно надо
исправить проблему с моим контроллером (и похоже с некоторыми другими),
потому что это стоило только мне и некоторым людям в этой рассылке
изрядного времени. А сколько ещё людей наткнётся на это сообщение fdisk?
Я в принципе ранее тоже предполагал что значительного влияния
выравнивание не должно оказывать, но проблема в том что у меня есть
очень серьёзный затык с производительностью и я ищу виноватых.
Предыстория такова: я использую backuppc для бэкапов и какое-то
неопределённое время назад он начал ставить на колени всю систему во
время бэкапа. При этом не происходит супер интенсивного ввода-вывода и
процессор не очень загружен, памяти свободной достаточно. При попытке
обращения к диску процессы останавливаются, пользоваться системой
практически невозможно.
Сейчас я переношу бэкап на новый винчестер и для меня крайне важно
исключить любые потенциальные источники тормозов, чтобы попытаться
найти настоящий источник такого замедления работы всей системы.
Перенос базы данных бэкапа занимает несколько дней, так что у меня нет
возможности экспериментировать со всеми возможными комбинациями
выравниванмий и шифрований. Но пожалуй эксперимент с шифрованием и без
шифрования я проведу.
--
С уважением, Сергей Спиридонов
Reply to: