Re: выравнивание раздела: кому верить, fdisk или parted?
Sergey Spiridonov wrote: > On Fri, 13 Dec 2019 00:58:55 +0300 > "Andrey Jr. Melnikov" wrote: > > > Во-первых размер странный, не находишь? Почему он не дотягивает один > > > блок в 512 байт до 65536? Если это число из железа, то либо > > > железо сообщает неправильный размер, либо драйвер его > > > неправильно интерпретирует. А значит его можно подправить в > > > драйвере. > > Нет, не странный. Это дело двух USB железок какой поток данных они > > будут гонять. > Ты хочешь обвинить меня в том что я вмешиваюсь в > личные отношения двух железок? Ну тогда простите... Нет, я хочу сказать что ты ищщешь то, незнаю что. > А значение, между тем, более чем странное (либо его интерпретация). И > оно может использоваться не только в партед. Ооо, в /sys/* столько значений, столько значений.. > > [...] > > Потому, что parted - гендерно-нейтральная поделка. > Ну допустим и что дальше? Может быть баг-репорты слать не надо? Или > пользоваться запрещено? Да, не пиши, кто запрещает-то? Только вот авторы parted и так уже занимаются черной магией вокруг неведомых констант и чнинить это скорее всего не будут. > > Вот тебе с моей машины: > > > > # grep . /sys/block/sd*/queue/optimal_io_size > > /sys/block/sda/queue/optimal_io_size:0 > ... > > Изволите перестать писать на диски? Или писать по 0 байт? > Если бы я знал все ответы, не пришёл бы сюда за советом. > В данном случае предположу, что если у тебя нет оптимального размера, > то следует использовать любой кратный минимальному. Либо вообще любой > больше минимального. Ещё раз - никто кроме фирмвари диска не знает оптимальный размер. Там внутри - кэша, оптимизаторы, железный подсчет ECC и прочих рид-соломонов. и пишет оно за раза не разу не 4096 байт. > Глянь что у тебя в > cat /sys/block/sd*/queue/minimum_io_size > У меня там стоит 512 или 4096. То-же самое. И? > > А те, кто может вотнуть > > неформатированный блочный девайс - обладают знаниями про fdsik. А > > гнутый parted он опционален, в базовой поставке его нет. > А раз он опционален и в базовой поставке его нет то... Что? Баги > репортить и фиксить не надо? Пользоваться им запрещено? Ну тогда это Пользоваться - пользуйся, только не удивляйся, что софт делает что-то своё, а не то, что ты от него просил. > надо прописать в документации Дебиана. "Не пользуйтесь ничем, если оно > не в базовой поставке". Дак там примерно так и есть. То, что в base-system с багами, оно влияет на всех пользователей - то и чинится быстрее (или выбрасывается нахрен, если последний чинитель ушел в закат, а текущий маинтайнер занял позу "год не апдейтилось - значит протухло"). А то, что в optional - может быть у кого руки дойдут в этом тысячилетии. Пока parted 3.3 доберется до stable - собственно stable сменится 2 раза, а parted протухнет 3. > > Угадал. То, что ты не знаешь, что делашь - я сразу написал. И то, что > > ты не можешь внятно описать проблему - тоже. > > Ну уж как могу. За это прошу простить, если чем-то кого-то обидел. Ты бы лучше вместо рассматривания ненужных тебе циферок - показал вывод top/iotop/vmstat -w 5 в момент когда у тебя винт подключен через eSATA и всё стоит в позе 'D'.
Re: выравнивание раздела: кому верить, fdisk или parted?
On Fri, 13 Dec 2019 00:58:55 +0300 "Andrey Jr. Melnikov" wrote: > > Во-первых размер странный, не находишь? Почему он не дотягивает один > > блок в 512 байт до 65536? Если это число из железа, то либо > > железо сообщает неправильный размер, либо драйвер его > > неправильно интерпретирует. А значит его можно подправить в > > драйвере. > Нет, не странный. Это дело двух USB железок какой поток данных они > будут гонять. Ты хочешь обвинить меня в том что я вмешиваюсь в личные отношения двух железок? Ну тогда простите... А значение, между тем, более чем странное (либо его интерпретация). И оно может использоваться не только в партед. > [...] > Потому, что parted - гендерно-нейтральная поделка. Ну допустим и что дальше? Может быть баг-репорты слать не надо? Или пользоваться запрещено? > Вот тебе с моей машины: > > # grep . /sys/block/sd*/queue/optimal_io_size > /sys/block/sda/queue/optimal_io_size:0 ... > Изволите перестать писать на диски? Или писать по 0 байт? Если бы я знал все ответы, не пришёл бы сюда за советом. В данном случае предположу, что если у тебя нет оптимального размера, то следует использовать любой кратный минимальному. Либо вообще любой больше минимального. Глянь что у тебя в cat /sys/block/sd*/queue/minimum_io_size У меня там стоит 512 или 4096. > А те, кто может вотнуть > неформатированный блочный девайс - обладают знаниями про fdsik. А > гнутый parted он опционален, в базовой поставке его нет. А раз он опционален и в базовой поставке его нет то... Что? Баги репортить и фиксить не надо? Пользоваться им запрещено? Ну тогда это надо прописать в документации Дебиана. "Не пользуйтесь ничем, если оно не в базовой поставке". > Угадал. То, что ты не знаешь, что делашь - я сразу написал. И то, что > ты не можешь внятно описать проблему - тоже. Ну уж как могу. За это прошу простить, если чем-то кого-то обидел. -- С уважением, Сергей Спиридонов
Re: выравнивание раздела: кому верить, fdisk или parted?
Sergey Spiridonov wrote: > Приветствую > > > Не понял тебя. В соответствующий драйвер можно USB UASP внести > > > изменение, и он будет поправлять optimal_io, в зависимости от усб > > > идентификатора, то есть возвращать либо 0 либо 33554432, вместо > > > 33553920, как сейчас. > > Ещё раз и меедленно - эта цифра обозначает максимальный > > размер одного URB между USB девайсами. К твоему винту она не > > относится совсем никак. > Во-первых размер странный, не находишь? Почему он не дотягивает один > блок в 512 байт до 65536? Если это число из железа, то либо > железо сообщает неправильный размер, либо драйвер его > неправильно интерпретирует. А значит его можно подправить в драйвере. Нет, не странный. Это дело двух USB железок какой поток данных они будут гонять. > Во-вторых если это просто максимальный размер URB между USB девайсами, Потому, что parted - гендерно-нейтральная поделка. > почему это значение используется для выравнивания? Ведь в руководстве > parted написано что выравнивание должно быть кратно размеру физического > сектора, который равен в данном случае 4096. Это правило здесь явно > нарушается - а значит необходимо поправить либо код, либо > руководство parted, а может и то и другое. Вот тебе с моей машины: # grep . /sys/block/sd*/queue/optimal_io_size /sys/block/sda/queue/optimal_io_size:0 /sys/block/sdb/queue/optimal_io_size:0 /sys/block/sdc/queue/optimal_io_size:0 /sys/block/sdd/queue/optimal_io_size:0 /sys/block/sde/queue/optimal_io_size:0 /sys/block/sdf/queue/optimal_io_size:0 /sys/block/sdg/queue/optimal_io_size:0 /sys/block/sdh/queue/optimal_io_size:0 /sys/block/sdi/queue/optimal_io_size:0 /sys/block/sdj/queue/optimal_io_size:0 # grep . /sys/block/sd*/alignment_offset /sys/block/sda/alignment_offset:0 /sys/block/sdb/alignment_offset:0 /sys/block/sdc/alignment_offset:0 /sys/block/sdd/alignment_offset:0 /sys/block/sde/alignment_offset:0 /sys/block/sdf/alignment_offset:0 /sys/block/sdg/alignment_offset:0 /sys/block/sdh/alignment_offset:0 /sys/block/sdi/alignment_offset:0 /sys/block/sdj/alignment_offset:0 Изволите перестать писать на диски? Или писать по 0 байт? > > > Я читал что шифрование само по себе не должно добавлять много > > > тормозов, если ЦПУ поддерживает аппаратное ускорение AES. По > > > крайней мере, так > > Если поддерживает. Вот куча всякого MIPS/ARM железа - не > > поддерживает. А в качестве микросервера с USB3 для бакапов спрятанное > > в кладовке имеет место быть. > Я писал, какое у меня железо. > > Муххахха. Скорость хреновой флешки. > Это ещё цветочки, но при этом хотя бы пользоваться системой вполне > реально. > > Нисколько. За них инсталлер сам всё разметит, с учетом эмпирической > > цифры в 2048 секторов, которой "должно хватить на любой алигн для > Какой ещё инсталлер? При чём тут инсталлер? Проблема с parted. Впрочем > в инсталлере тоже может быть подобный баг. Такой инсталлер, которым debian ставят. Ибо расчитано под один раз разбили и поставили, а флешки и прочая usb-хрень уже воткнута отформатированной в fat/exfat/ntfs. А те, кто может вотнуть неформатированный блочный девайс - обладают знаниями про fdsik. А гнутый parted он опционален, в базовой поставке его нет. > > Выкинь нахрен свою USB корзинку, распечатай и повесь на стенку плакат > ... > > > Предыстория такова: > > ... ты купил какой-то шлак, вместо банальной корзинки с eSATA > > подключением и теперь занимаешься починкой нечинимого. > Как говорится, играл, но не угадал ни одой буквы. На УСБ3 я перешёл как > раз с eSATA. По причине тех же затыков и тормозов. Угадал. То, что ты не знаешь, что делашь - я сразу написал. И то, что ты не можешь внятно описать проблему - тоже.
Re: выравнивание раздела: кому верить, fdisk или parted?
Sergey Spiridonov wrote: > On Tue, 10 Dec 2019 17:19:01 +0300 > "Andrey Jr. Melnikov" wrote: > > Sergey Spiridonov 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, как сейчас. Ещё раз и меедленно - эта цифра обозначает максимальный размер одного URB между USB девайсами. К твоему винту она не относится совсем никак. > > > Я согласен уже на всё, но какой брать отступ? Какие для этого есть > > > правила??? > > > > Никакой. > В смысле 0? Да хоть и 0. > > > Я потом раздел шифрую люксом, это как-то влияет? > > Да, всё тормозит на шифровании. > Я читал что шифрование само по себе не должно добавлять много тормозов, > если ЦПУ поддерживает аппаратное ускорение AES. По крайней мере, так Если поддерживает. Вот куча всякого MIPS/ARM железа - не поддерживает. А в качестве микросервера с USB3 для бакапов спрятанное в кладовке имеет место быть. > пишут собаководы [1]. И это для SSD! Для шпинделя должно быть вообще > незаметно, ведь поток данных в разы меньше. Поток тот-же, скорость записи другая. > Сам проверял это записывая большой файл на вышеупомянутую зашифрованную > шпиндельную Тошибу. Скорость записи в 260МБ/с меня вполне устроила. При 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? Нисколько. За них инсталлер сам всё разметит, с учетом эмпирической цифры в 2048 секторов, которой "должно хватить на любой алигн для любого применения". Особенно красиво, когда бегают с SSD под RAID контроллером и оправдывают такой алигмент "структурами raid", а то, что они хранятся обычно в конце диска - ну это извсетно только производителю, д. > Я в принципе ранее тоже предполагал что значительного влияния > выравнивание не должно оказывать, но проблема в том что у меня есть > очень серьёзный затык с производительностью и я ищу виноватых. Выкинь нахрен свою USB корзинку, распечатай и повесь на стенку плакат с надписюь "USB только для мышек" и при любом желании купить что-то с USB смотри на него до просветления. И да, мышки тоже лучше брать не USB. > Предыстория такова: ... ты купил какой-то шлак, вместо банальной корзинки с eSATA подключением и теперь занимаешься починкой нечинимого. Если тебе хочется быстро - то твой выбор eSATA/Thunderolt 3. А сейчас у тебя "универсально" - т.е. одинаково погано в любом месте. Возможно, USB4 изменит ситуацию - но лет через 5, как китайцы массово научатся клепать дешевые чипы с "USB4 ready*". *) limited subset of USB4 is supported.
Re: выравнивание раздела: кому верить, fdisk или parted?
On Tue, 10 Dec 2019 17:19:01 +0300 "Andrey Jr. Melnikov" wrote: > Sergey Spiridonov 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 для бэкапов и какое-то неопределённое время назад он начал ставить на колени всю систему во время бэкапа. При этом не происходит супер интенсивного ввода-вывода и процессор не очень загружен, памяти свободной достаточно. При попытке обращения к диску процессы останавливаются, пользоваться системой практически невозможно. Сейчас я переношу бэкап на новый винчестер и для меня крайне важно исключить любые потенциальные источники тормозов, чтобы попытаться найти настоящий источник такого замедления работы всей системы. Перенос базы данных бэкапа занимает несколько дней, так что у меня нет возможности экспериментировать со всеми возможными комбинациями выравниванмий и шифрований. Но пожалуй эксперимент с шифрованием и без шифрования я проведу. -- С уважением, Сергей Спиридонов
Re: выравнивание раздела: кому верить, fdisk или parted?
Sergey Spiridonov wrote: > В Thu, 5 Dec 2019 17:38:02 +0300 (MSK) > yuri.nefe...@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.
Re: выравнивание раздела: кому верить, fdisk или parted?
On Sat, Dec 07, 2019 at 03:12:57PM +0300, Victor Wagner wrote: > В Sat, 7 Dec 2019 12:40:23 +0300 > Eugene Berdnikov пишет: > > > > > > By default, Linux follows an optimistic memory allocation > > > > strategy. This means that when malloc() returns non-NULL there is > > > > no guarantee that the memory really is available. In case it > > > > turns out that the system is out of memory, one or more processes > > > > will be killed by the OOM killer. > > > > Мне что-то подсказывает, что выставление лимитов на память для > > процесса и лимитов на количество процессов позволяют свести оптимизм > > к величине, соответствующей объёму физической памяти. > > может проще сказать > > sysctl vm.overcommit_memory=1 В плане убиения оверкоммита да, проще. Но один лишь глобальный лимит позволяет одному раздувшемуся процессу съесть весь ресурс компьютера, не оставив ничего другим процессам. Это типичная аварийная ситуация. В плане гранулярности лучше лимиты на процессы и/или cgroups. Ну и для полноты картины полезно знать, что есть "vm.swappiness". Про него можно сообщить авторам дурацких идей по удалению свопа. -- Eugene Berdnikov
Re: выравнивание раздела: кому верить, fdisk или parted?
В Sat, 7 Dec 2019 12:40:23 +0300 Eugene Berdnikov пишет: > > > By default, Linux follows an optimistic memory allocation > > > strategy. This means that when malloc() returns non-NULL there is > > > no guarantee that the memory really is available. In case it > > > turns out that the system is out of memory, one or more processes > > > will be killed by the OOM killer. > > Мне что-то подсказывает, что выставление лимитов на память для > процесса и лимитов на количество процессов позволяют свести оптимизм > к величине, соответствующей объёму физической памяти. может проще сказать sysctl vm.overcommit_memory=1 ? -- Victor Wagner
Re: выравнивание раздела: кому верить, fdisk или parted?
On Fri, Dec 06, 2019 at 10:25:04PM +0300, Alexander Galanin wrote: > 06.12.2019 22:03, Eugene Berdnikov пишет: > >> Не всегда сегфолт лучше, чем замедление работы :) > > > > Ну... иногда бывает лучше. :) Потому что даёт право вынуть из ножен > > мечик и помахать по кривым рукам разрабов, которые не проверяют код > > возврата из malloc(). > > Проверяй-не проверяй, всё равно гарантий нет: > > > By default, Linux follows an optimistic memory allocation strategy. This > > means > > that when malloc() returns non-NULL there is no guarantee that the memory > > really is available. In case it turns out that the system is out of memory, > > one or more processes will be killed by the OOM killer. Мне что-то подсказывает, что выставление лимитов на память для процесса и лимитов на количество процессов позволяют свести оптимизм к величине, соответствующей объёму физической памяти. -- Eugene Berdnikov
Re: выравнивание раздела: кому верить, fdisk или parted?
06.12.2019 22:03, Eugene Berdnikov пишет: >> Не всегда сегфолт лучше, чем замедление работы :) > > Ну... иногда бывает лучше. :) Потому что даёт право вынуть из ножен > мечик и помахать по кривым рукам разрабов, которые не проверяют код > возврата из malloc(). Проверяй-не проверяй, всё равно гарантий нет: > By default, Linux follows an optimistic memory allocation strategy. This means > that when malloc() returns non-NULL there is no guarantee that the memory > really is available. In case it turns out that the system is out of memory, > one or more processes will be killed by the OOM killer. -- Alexander Galanin
Re: выравнивание раздела: кому верить, fdisk или parted?
On Fri, Dec 06, 2019 at 10:03:39PM +0300, Eugene Berdnikov wrote: > > Не всегда сегфолт лучше, чем замедление работы :) > > Ну... иногда бывает лучше. :) Потому что даёт право вынуть из ножен мечик > и помахать по кривым рукам разрабов, которые не проверяют код возврата > из malloc(). Правда, если прога чужая и без техподдержки, то поймать > автора и применить серп к его яйцам будет проблематично.. С тех пор как появилось сжатие swap, то это не всегда даже существенное замедление работы.
Re: выравнивание раздела: кому верить, fdisk или parted?
On Fri, Dec 06, 2019 at 05:19:20PM +0300, Artem Chuprina wrote: > yuri.nefe...@gmail.com -> debian-russian@lists.debian.org @ Fri, 6 Dec 2019 > 12:01:42 +0300 (MSK): > > >>> Лучше не напрягать мозг и не делать ни отступов ни таблиц разделов. > >> > >> Своп тоже не делать, чтобы мозг не перегрелся? :) > >> -- > >> Eugene Berdnikov > >> > > Опасно так шутить. > > Вот в планах по оптимизации кластера для обработки данных > > стоит - удалить своп. > > (Кусочек из презентации в приложении.) > > Не всегда сегфолт лучше, чем замедление работы :) Ну... иногда бывает лучше. :) Потому что даёт право вынуть из ножен мечик и помахать по кривым рукам разрабов, которые не проверяют код возврата из malloc(). Правда, если прога чужая и без техподдержки, то поймать автора и применить серп к его яйцам будет проблематично... В принципе, отсутствие свопа -- это не повод для сегфолта. В теории. На практике же выход за пределы RAM приводит к отказам на выделение памяти, а для абсолютного большинства программ это столь же фатально, как сегфолт. Наличие свопа позволяет эту (аварийную по сути) ситуацию перевести в разряд "неэффективной работы". Отказываться от свопа как средства избежать катастрофы -- это глупость примерно того же плана, как предложение удалить спасательные шлюпки с палубы Титаника, потому что идти в океане на вёслах неэффективно. -- Eugene Berdnikov
Re: выравнивание раздела: кому верить, fdisk или parted?
On Fri, 6 Dec 2019, Artem Chuprina wrote: yuri.nefe...@gmail.com -> debian-russian@lists.debian.org @ Fri, 6 Dec 2019 12:01:42 +0300 (MSK): >>> Лучше не напрягать мозг и не делать ни отступов ни таблиц разделов. >> >> Своп тоже не делать, чтобы мозг не перегрелся? :) >> -- >> Eugene Berdnikov >> > Опасно так шутить. > Вот в планах по оптимизации кластера для обработки данных > стоит - удалить своп. > (Кусочек из презентации в приложении.) Не всегда сегфолт лучше, чем замедление работы :) Я бы сказал, что всегда хуже, особенно когда куча ядер и на каждом по задаче крутится. Статистику наберут и следующая оптимизация будет - добавление свопа. Ю.
Re: выравнивание раздела: кому верить, fdisk или parted?
yuri.nefe...@gmail.com -> debian-russian@lists.debian.org @ Fri, 6 Dec 2019 12:01:42 +0300 (MSK): >>> Лучше не напрягать мозг и не делать ни отступов ни таблиц разделов. >> >> Своп тоже не делать, чтобы мозг не перегрелся? :) >> -- >> Eugene Berdnikov >> > Опасно так шутить. > Вот в планах по оптимизации кластера для обработки данных > стоит - удалить своп. > (Кусочек из презентации в приложении.) Не всегда сегфолт лучше, чем замедление работы :)
Re: выравнивание раздела: кому верить, fdisk или parted?
On 06/12/2019 12:58, Victor Wagner wrote: > и в одном 512-байтном секторе Но мир не стоит на месте, и выравнивания по 512 байт уже не достаточно. >> # cat /sys/block/sdd/queue/minimum_io_size >> 4096 БАЙТ > Мне кажется, 2048s для начала раздела довольно оптимальный > выбор. Не вижу причин брать больший отступ. 2048s = 1 мегабайт Самый большой размер в современном мире, по которому может требоваться выравнивание это eraseblock. Как пишут в интырнетах он может достигать 4Mb. А ещё может быть не круглым: 1.5Mb (из-за Triple Level Cell) Интересно, как его узнать? Я знаю два способа: 1. посмотреть в документацию 2. тест на скорость на блоках разного размера. Современные магнитные диски могут иметь размер блока до 4Kb (или бывает больше?) -- sergio.
Re: выравнивание раздела: кому верить, fdisk или parted?
On Fri, 6 Dec 2019 12:51:18 +0300 sergio wrote: > On 06/12/2019 12:24, Sergey Spiridonov wrote: > > > Хорошая идея на первый взгляд. Но почему-то fdisk всё равно делает > > отступ. Может быть в этом есть какой-то сокрытый смысл? > > А в вашем представлении сама таблица разделов места не занимает? А, точно! Попробую без таблицы. -- С уважением, Сергей Спиридонов
Re: выравнивание раздела: кому верить, fdisk или parted?
On Fri, 6 Dec 2019 12:51:18 +0300 sergio wrote: > On 06/12/2019 12:24, Sergey Spiridonov wrote: > > > Хорошая идея на первый взгляд. Но почему-то fdisk всё равно делает > > отступ. Может быть в этом есть какой-то сокрытый смысл? > > А в вашем представлении сама таблица разделов места не занимает? > Насколько я помню те времена, когда я копался в загрузочных секторах с шестнадцатиричным редактором и дизассемблером, она занимает 64 байта, и в одном 512-байтном секторе с ней умещается еще и загрузочный код MBR и 2-байтовая сигнатура в конце.
Re: выравнивание раздела: кому верить, fdisk или parted?
On 06/12/2019 12:24, Sergey Spiridonov wrote: > Хорошая идея на первый взгляд. Но почему-то fdisk всё равно делает > отступ. Может быть в этом есть какой-то сокрытый смысл? А в вашем представлении сама таблица разделов места не занимает? -- sergio.
Re: выравнивание раздела: кому верить, fdisk или parted?
On Fri, 6 Dec 2019 12:12:10 +0300 (MSK) yuri.nefe...@gmail.com wrote: > Мне кажется, 2048s для начала раздела довольно оптимальный > выбор. Не вижу причин брать больший отступ. А ведь это ещё не всё. Ведь само ядро использует это неверное значение optimal_io_size для ввода-вывода! Надо, выходит, всё равно править драйвер? Сейчас проверил скорость копирования - 17 МБ/с при подключённом через SATA диске. Через УСБ - ещё в два раза меньше. -- С уважением, Сергей Спиридонов
Re: выравнивание раздела: кому верить, fdisk или parted?
Привет On Fri, 6 Dec 2019 08:08:50 +0300 sergio wrote: > On 06/12/2019 07:16, Sergey Spiridonov wrote: > > > Какой отступ лучше брать? > > Лучше не напрягать мозг и не делать ни отступов ни таблиц разделов. Хорошая идея на первый взгляд. Но почему-то fdisk всё равно делает отступ. Может быть в этом есть какой-то сокрытый смысл? -- С уважением, Сергей Спиридонов
Re: выравнивание раздела: кому верить, fdisk или parted?
On Fri, 6 Dec 2019, Sergey Spiridonov wrote: В Fri, 6 Dec 2019 04:23:05 +0100 Sergey Spiridonov пишет: Или лучше достать диск, разбить на разделы и вставить обратно? А не будет ли при этом потом проблем с УСБ контроллером? Вытащил диск, подключил напрямую. Теперь # cat /sys/block/sdd/queue/optimal_io_size 0 # cat /sys/block/sdd/queue/minimum_io_size 4096 Какой отступ лучше брать? -- С уважением, Сергей Спиридонов Мне кажется, 2048s для начала раздела довольно оптимальный выбор. Не вижу причин брать больший отступ. Ю.
Re: выравнивание раздела: кому верить, fdisk или parted?
On Fri, 6 Dec 2019, Eugene Berdnikov wrote: On Fri, Dec 06, 2019 at 08:08:50AM +0300, sergio wrote: On 06/12/2019 07:16, Sergey Spiridonov wrote: Какой отступ лучше брать? Лучше не напрягать мозг и не делать ни отступов ни таблиц разделов. Своп тоже не делать, чтобы мозг не перегрелся? :) -- Eugene Berdnikov Опасно так шутить. Вот в планах по оптимизации кластера для обработки данных стоит - удалить своп. (Кусочек из презентации в приложении.) Ю.
Re: выравнивание раздела: кому верить, fdisk или parted?
On 06/12/2019 10:53, Eugene Berdnikov wrote: > Своп тоже не делать, чтобы мозг не перегрелся? :) > Disk /dev/sdd: 12,8 TiB, 14000519643136 bytes, 27344764928 sectors ... > Device Start End Sectors Size Type > /dev/sdd1 65535 27344740889 27344675355 12,8T Linux filesystem Чё-то я не наблюдаю тут ни свапа ни йэфи ни эльвиэма, только лишь один раздел размером во весь usb диск. -- sergio.
Re: выравнивание раздела: кому верить, fdisk или parted?
On Fri, Dec 06, 2019 at 08:08:50AM +0300, sergio wrote: > On 06/12/2019 07:16, Sergey Spiridonov wrote: > > > Какой отступ лучше брать? > > Лучше не напрягать мозг и не делать ни отступов ни таблиц разделов. Своп тоже не делать, чтобы мозг не перегрелся? :) -- Eugene Berdnikov
Re: выравнивание раздела: кому верить, fdisk или parted?
On 06/12/2019 07:16, Sergey Spiridonov wrote: > Какой отступ лучше брать? Лучше не напрягать мозг и не делать ни отступов ни таблиц разделов. -- sergio.
Re: выравнивание раздела: кому верить, fdisk или parted?
В Fri, 6 Dec 2019 04:23:05 +0100 Sergey Spiridonov пишет: > Или лучше достать диск, разбить на разделы и вставить обратно? А не > будет ли при этом потом проблем с УСБ контроллером? Вытащил диск, подключил напрямую. Теперь # cat /sys/block/sdd/queue/optimal_io_size 0 # cat /sys/block/sdd/queue/minimum_io_size 4096 Какой отступ лучше брать? -- С уважением, Сергей Спиридонов
Re: выравнивание раздела: кому верить, fdisk или parted?
В Thu, 5 Dec 2019 17:38:02 +0300 (MSK) yuri.nefe...@gmail.com пишет: > Боюсь, что баг-репорт не поможет, хотя можете попробовать. Ну да, они скажут что виноват драйвер кернела, который неправильно понимает УСБ-Контроллер... Наверное надо куда-то в кернел писать? > Одно из возможных объяснений: > ICY BOX IB-366StU3+B - это ведь enclosure for USB 3.0? Да > Если контролер этой штуки прописывает optimal_io_size > как 33553920 (65535*512) то выравнивается именно на эту величину. Угу, по крайней мере кернел сообщает эту цифру. # cat /sys/block/sdd/queue/optimal_io_size 33553920, что и даёт искомые 65535 при делении на 512. # cat /sys/block/sdd/queue/minimum_io_size 4096 > Так что остается один путь, сделать разбиение вручную. Я согласен уже на всё, но какой брать отступ? Какие для этого есть правила??? Например, если я правильно понял, fdisk отступил 2048 логических сектора по 512 байт. Это хорошо? Это нормально? Или лучше отступить 65536? Может ошибка контроллера - сообщать 65535 вместо 65536. Или это неправильная интерпретация стандарта, одни считают от 0, другие от 1? Или лучше достать диск, разбить на разделы и вставить обратно? А не будет ли при этом потом проблем с УСБ контроллером? Я потом раздел шифрую люксом, это как-то влияет? Спасибо за помощь. Блин, 2019 год, а в линуксе проблема разбить винт. Куда катится мир? -- С уважением, Сергей Спиридонов
Re: выравнивание раздела: кому верить, fdisk или parted?
On Thu, 5 Dec 2019, Sergey Spiridonov wrote: В Wed, 4 Dec 2019 07:31:26 +0300 (MSK) yuri.nefe...@gmail.com пишет: У parted есть опция unit (parted) print unit "s" Посмотрите, что она выдаст. В общем, что с выравниванием по цилиндру, что с "оптимальным" выравниванием, режет физический сектор на куски. Почему - непонятно. При это fdisk делает выравнивает на 4096 байт. Наверное надо слать багрепорт на партед? # parted -a cyl /dev/sdd GNU Parted 3.2 Using /dev/sdd Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) mkpart primary 0% 100% (parted) print unit "s" Model: ICY BOX IB-366StU3+B (scsi) Disk /dev/sdd: 14000519643136B Sector size (logical/physical): 512B/4096B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 17408B 14000519626239B 14000519608832B primary (parted) print Model: ICY BOX IB-366StU3+B (scsi) Disk /dev/sdd: 27344764928s Sector size (logical/physical): 512B/4096B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 34s27344764894s 27344764861s primary # parted -a opt /dev/sdd GNU Parted 3.2 Using /dev/sdd Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) rm 1 (parted) mkpart primary 0% 100% (parted) print unit "s" Model: ICY BOX IB-366StU3+B (scsi) Disk /dev/sdd: 14,0TB Sector size (logical/physical): 512B/4096B Partition Table: gpt Disk Flags: Number Start End SizeFile system Name Flags 1 33,6MB 14,0TB 14,0TB primary (parted) print Model: ICY BOX IB-366StU3+B (scsi) Disk /dev/sdd: 27344764928s Sector size (logical/physical): 512B/4096B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 65535s 27344740889s 27344675355s primary -- С уважением, Сергей Спиридонов Боюсь, что баг-репорт не поможет, хотя можете попробовать. Одно из возможных объяснений: ICY BOX IB-366StU3+B - это ведь enclosure for USB 3.0? Если контролер этой штуки прописывает optimal_io_size как 33553920 (65535*512) то выравнивается именно на эту величину. Логика работы parted строится таким образом [1]: The heuristic parted uses is: 1) Always use the reported 'alignment_offset' as the offset for the start of the first primary partition. 2a) If 'optimal_io_size' is defined (not 0) align all partitions on an 'optimal_io_size' boundary. 2b) If 'optimal_io_size' is undefined (0) and 'alignment_offset' is 0 and 'minimum_io_size' is a power of 2: use a 1MB default alignment. - as you can see this is the catch all for "legacy" devices which don't appear to provide "I/O hints"; so in the default case all partitions will align on a 1MB boundary. - NOTE: we can't distinguish between a "legacy" device and modern device that provides "I/O hints" with alignment_offset=0 and optimal_io_size=0. Such a device might be a single SAS 4K device. So worst case we lose < 1MB of space at the start of the disk. Для доступа к этим параметрам используют sys интерфейс [1]: sysfs interface --- /sys/block//alignment_offset /sys/block///alignment_offset /sys/block//queue/physical_block_size /sys/block//queue/logical_block_size /sys/block//queue/minimum_io_size /sys/block//queue/optimal_io_size Ради любопытства, что выдает? /sys/block//queue/optimal_io_size Так что остается один путь, сделать разбиение вручную. > parted -a none (parted) mkpart primary ext4 2048s 100% Ю. [1] https://people.redhat.com/msnitzer/docs/io-limits.txt
Re: выравнивание раздела: кому верить, fdisk или parted?
В Wed, 4 Dec 2019 07:31:26 +0300 (MSK) yuri.nefe...@gmail.com пишет: >У parted есть опция unit >(parted) print unit "s" > >Посмотрите, что она выдаст. В общем, что с выравниванием по цилиндру, что с "оптимальным" выравниванием, режет физический сектор на куски. Почему - непонятно. При это fdisk делает выравнивает на 4096 байт. Наверное надо слать багрепорт на партед? # parted -a cyl /dev/sdd GNU Parted 3.2 Using /dev/sdd Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) mkpart primary 0% 100% (parted) print unit "s" Model: ICY BOX IB-366StU3+B (scsi) Disk /dev/sdd: 14000519643136B Sector size (logical/physical): 512B/4096B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 17408B 14000519626239B 14000519608832B primary (parted) print Model: ICY BOX IB-366StU3+B (scsi) Disk /dev/sdd: 27344764928s Sector size (logical/physical): 512B/4096B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 34s27344764894s 27344764861s primary # parted -a opt /dev/sdd GNU Parted 3.2 Using /dev/sdd Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) rm 1 (parted) mkpart primary 0% 100% (parted) print unit "s" Model: ICY BOX IB-366StU3+B (scsi) Disk /dev/sdd: 14,0TB Sector size (logical/physical): 512B/4096B Partition Table: gpt Disk Flags: Number Start End SizeFile system Name Flags 1 33,6MB 14,0TB 14,0TB primary (parted) print Model: ICY BOX IB-366StU3+B (scsi) Disk /dev/sdd: 27344764928s Sector size (logical/physical): 512B/4096B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 65535s 27344740889s 27344675355s primary -- С уважением, Сергей Спиридонов
Re: выравнивание раздела: кому верить, fdisk или parted?
On Wed, 4 Dec 2019, Sergey Spiridonov wrote: On Wed, 4 Dec 2019 09:05:34 +0300 (MSK) yuri.nefe...@gmail.com wrote: Так ведь и не должна быть кратной. Запрошено: > parted -a opt /dev/sdd ман parted optimal Use optimum alignment as given by the disk topology in‐ formation. This aligns to a multiple of the physical block size in a way that guarantees optimal performance. Так и сделали оптимальной. Секундочку! Написано что на множитель физического блока, причём "гарантирующим оптимальную производительность". hdparm -I /dev/sdd выдаёт мне Logical Sector size: 512 bytes Physical Sector size: 4096 bytes Размер сектора 4096, а выравнивание почему-то на 512 байт. Ну ладно, партед решил почему-то что физический блок 512 байт, но зачем выбирать нечётный множитель? В чём геометрический смысл нечётного множителя??? А если надо было что бы по границе то cylinder Align partitions to cylinders. Посмотрю вечером. -- С уважением, Сергей Спиридонов Фигню я какую то утром написал. Пардон. А там диск не через USB цепляется? Некоторые контролеры имеют свойство "подправлять" конфигурацию диска. Что то мне припоминается, что как раз эти магические 65535 как раз в этом случае и всплывали. Решалось форматированием в gdisk. Похожая ошибка тут вот: https://github.com/karelzak/util-linux/commit/acb7651f8897ae73d0f45dd75bc87630001c61b9 Можете проверить, что у вас показывает /sys/block//queue/optimal_io_size If 'optimal_io_size' is defined (not 0) align all partitions on an 'optimal_io_size' boundary. Эта гадость и сбивает все. Ю.
Re: выравнивание раздела: кому верить, fdisk или parted?
Victor Wagner wrote: > On Wed, 4 Dec 2019 10:42:55 +0100 > Sergey Spiridonov wrote: > > On Wed, 04 Dec 2019 08:45:30 +0300 > > Max Kosmach wrote: > > > > > >Device Start End Sectors Size Type > > > >/dev/sdd1 65535 27344740889 27344675355 12,8T Linux filesystem > > > > > > > >Partition 1 does not start on physical sector boundary. > > > > > > Вроде ж правда написана - 512*65535 не кратно 4к? > > > > Почему parted начинает с 65535, а не с 65536? В чём логика? > По-моему, это когда-то, лет 15 назад типичный диск имел 63 сектора на > дорожку. Да-да. тех самых, 512 байтных. С тех пор и осталась идея > выравнивать на "границу цилиндра". Лет 20 назад с помошью Norton Disk Destroyer еще сильно помогало форматировать оныый диск с sector interleave - становилось сильно быстрее. 15 лет назад диски уже вовсю врали BIOSу про 63 сектора. Догадаешься, почему? PS: Для тех кому лень догадываться, или не знал и забыл: Int 13/AH=08h DISK - GET DRIVE PARAMETERS (PC,XT286,CONV,PS,ESDI,SCSI) AH = 08h DL = drive (bit 7 set for hard disk) ES:DI = h:h to guard against BIOS bugs Return: CF set on error AH = status (07h) (see #00234) CF clear if successful AH = 00h AL = 00h on at least some BIOSes BL = drive type (AT/PS2 floppies only) (see #00242) CH = low eight bits of maximum cylinder number CL = maximum sector number (bits 5-0) high two bits of maximum cylinder number (bits 7-6) DH = maximum head number DL = number of drives ES:DI -> drive parameter table (floppies only)
Re: выравнивание раздела: кому верить, fdisk или parted?
On Wed, 4 Dec 2019 10:42:55 +0100 Sergey Spiridonov wrote: > On Wed, 04 Dec 2019 08:45:30 +0300 > Max Kosmach wrote: > > > >Device Start End Sectors Size Type > > >/dev/sdd1 65535 27344740889 27344675355 12,8T Linux filesystem > > > > > >Partition 1 does not start on physical sector boundary. > > > > Вроде ж правда написана - 512*65535 не кратно 4к? > > Почему parted начинает с 65535, а не с 65536? В чём логика? По-моему, это когда-то, лет 15 назад типичный диск имел 63 сектора на дорожку. Да-да. тех самых, 512 байтных. С тех пор и осталась идея выравнивать на "границу цилиндра". --
Re: выравнивание раздела: кому верить, fdisk или parted?
On Wed, 4 Dec 2019, Max Kosmach wrote: 4 декабря 2019 г. 3:03:02 GMT+03:00, Sergey Spiridonov пишет: Disk /dev/sdd: 12,8 TiB, 14000519643136 bytes, 27344764928 sectors Disk model: IB-366StU3+B Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 33553920 bytes Device Start End Sectors Size Type /dev/sdd1 65535 27344740889 27344675355 12,8T Linux filesystem Partition 1 does not start on physical sector boundary. Вроде ж правда написана - 512*65535 не кратно 4к? Так ведь и не должна быть кратной. Запрошено: > parted -a opt /dev/sdd ман parted optimal Use optimum alignment as given by the disk topology in‐ formation. This aligns to a multiple of the physical block size in a way that guarantees optimal performance. Так и сделали оптимальной. А если надо было что бы по границе то cylinder Align partitions to cylinders. Или minimal Use minimum alignment as given by the disk topology in‐ formation. This and the opt value will use layout infor‐ mation provided by the disk to align the logical parti‐ tion table addresses to actual physical blocks on the disks. The min value is the minimum alignment needed to align the partition properly to physical blocks, which avoids performance degradation. Опять же, что спрошено, то и получено... Ю.
Re: выравнивание раздела: кому верить, fdisk или parted?
4 декабря 2019 г. 3:03:02 GMT+03:00, Sergey Spiridonov пишет: >Disk /dev/sdd: 12,8 TiB, 14000519643136 bytes, 27344764928 sectors >Disk model: IB-366StU3+B >Units: sectors of 1 * 512 = 512 bytes >Sector size (logical/physical): 512 bytes / 4096 bytes >I/O size (minimum/optimal): 4096 bytes / 33553920 bytes >Device Start End Sectors Size Type >/dev/sdd1 65535 27344740889 27344675355 12,8T Linux filesystem > >Partition 1 does not start on physical sector boundary. Вроде ж правда написана - 512*65535 не кратно 4к? -- Max Kosmach
Re: выравнивание раздела: кому верить, fdisk или parted?
On Wed, 4 Dec 2019, nefedov.y...@jinr.ru wrote: On Wed, 4 Dec 2019, Sergey Spiridonov wrote: Всем привет создаю раздел на винчестере # parted -a opt /dev/sdd (parted) mkpart primary 0% 100% (parted) print Number Start End SizeFile system Name Flags 1 33,6MB 14,0TB 14,0TB primary проверяем выравнивание (parted) align-check opt 1 1 aligned теперь с помощью fdisk: # fdisk /dev/sdd : p Disk /dev/sdd: 12,8 TiB, 14000519643136 bytes, 27344764928 sectors Disk model: IB-366StU3+B Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 33553920 bytes Disklabel type: gpt Disk identifier: 82DD924B-BF0E-40FF-9037-1FD4E7307D26 Device Start End Sectors Size Type /dev/sdd1 65535 27344740889 27344675355 12,8T Linux filesystem Partition 1 does not start on physical sector boundary. Кто из них врёт? -- С уважением, Сергей Спиридонов Если вас вторая граница беспокоит, то это разница между TiB и TB 12.8*(2**10)**4/1e12 = 14.0737488355328 Ю.
Re: выравнивание раздела: кому верить, fdisk или parted?
On Wed, 4 Dec 2019, Sergey Spiridonov wrote: Всем привет создаю раздел на винчестере # parted -a opt /dev/sdd (parted) mkpart primary 0% 100% (parted) print Number Start End SizeFile system Name Flags 1 33,6MB 14,0TB 14,0TB primary проверяем выравнивание (parted) align-check opt 1 1 aligned теперь с помощью fdisk: # fdisk /dev/sdd : p Disk /dev/sdd: 12,8 TiB, 14000519643136 bytes, 27344764928 sectors Disk model: IB-366StU3+B Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 33553920 bytes Disklabel type: gpt Disk identifier: 82DD924B-BF0E-40FF-9037-1FD4E7307D26 Device Start End Sectors Size Type /dev/sdd1 65535 27344740889 27344675355 12,8T Linux filesystem Partition 1 does not start on physical sector boundary. Кто из них врёт? -- С уважением, Сергей Спиридонов Не могли бы пояснить, в чем видите вранье? 65535 в единицах 512 байт (Units: sectors of 1 * 512 = 512 bytes) то есть 65535*512=33553920 То что parted и записал как 33.6MB У parted есть опция unit (parted) print unit "s" Посмотрите, что она выдаст. Ю. p.s. On Wed, 4 Dec 2019, sergio wrote: 65535 = 3*5*17*257 Принципиально не согласен! :) 65535 = 2**16-1 Число Мерсенна все же. :)
Re: выравнивание раздела: кому верить, fdisk или parted?
On 04/12/2019 03:03, Sergey Spiridonov wrote: > Device Start End Sectors Size Type > /dev/sdd1 65535 27344740889 27344675355 12,8T Linux filesystem ^ 65535 = 3*5*17*257 -- sergio.
выравнивание раздела: кому верить, fdisk или parted?
Всем привет создаю раздел на винчестере # parted -a opt /dev/sdd (parted) mkpart primary 0% 100% (parted) print Number Start End SizeFile system Name Flags 1 33,6MB 14,0TB 14,0TB primary проверяем выравнивание (parted) align-check opt 1 1 aligned теперь с помощью fdisk: # fdisk /dev/sdd : p Disk /dev/sdd: 12,8 TiB, 14000519643136 bytes, 27344764928 sectors Disk model: IB-366StU3+B Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 33553920 bytes Disklabel type: gpt Disk identifier: 82DD924B-BF0E-40FF-9037-1FD4E7307D26 Device Start End Sectors Size Type /dev/sdd1 65535 27344740889 27344675355 12,8T Linux filesystem Partition 1 does not start on physical sector boundary. Кто из них врёт? -- С уважением, Сергей Спиридонов
