On Tue, 10 Dec 2019 17:19:01 +0300 "Andrey Jr. Melnikov" <temnota...@gmail.com> wrote:
> Sergey Spiridonov <s...@s73.work> wrote: > > В Thu, 5 Dec 2019 17:38:02 +0300 (MSK) > > yuri.nefe...@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 для бэкапов и какое-то неопределённое время назад он начал ставить на колени всю систему во время бэкапа. При этом не происходит супер интенсивного ввода-вывода и процессор не очень загружен, памяти свободной достаточно. При попытке обращения к диску процессы останавливаются, пользоваться системой практически невозможно. Сейчас я переношу бэкап на новый винчестер и для меня крайне важно исключить любые потенциальные источники тормозов, чтобы попытаться найти настоящий источник такого замедления работы всей системы. Перенос базы данных бэкапа занимает несколько дней, так что у меня нет возможности экспериментировать со всеми возможными комбинациями выравниванмий и шифрований. Но пожалуй эксперимент с шифрованием и без шифрования я проведу. -- С уважением, Сергей Спиридонов
