Вопрос теории - выравнивание на винтах

Сейчас стали делать винты с размером сектора в 4 Mb. если разбивать без выравнивания, это серьёзно тормозит операции ввода/вывода.

Логически, естественно, размер сектора на таких винтах остался прежним.

> винты с размером сектора в 4 Mb.

Поделись веществами.

блин, 4кб естесственно.

>>anaconda у федоры пропускает от начала раздела 2047 секторов.

Сейчас стали делать винты с размером сектора в 4 kb. если разбивать без выравнивания, это серьёзно тормозит операции ввода/вывода.

Не вижу логики. Если размер раздела округляется до секторов¸то зачем их 2047 штук-то пропускать?

В общем, это делается на всякий случай, так? Мне с моим размером 512 килобайт логических и физических секторов можно не волноваться?

Первый на 2048-мом будет

Вопрос снят http://habrahabr.ru/company/paragon/blog/97436/

О, спасибо за ссылку, даже с картинками.

Да не очень. У этого кретина файловая система занимает место между сектором и разделом.

Не ругайте пианиста, он играет как умеет

>Первый на 2048-мом будет

А я всё равно не догнал. Ну и пусть первый сектор будет на 2048, но пропущено-то 2047 и начало раздела будет не на границе секторов. Тут что-то другое (или что-то ещё) учитывается

Глянул на виртуалку. Это топикстартер всё напутал, нумерация идёт с нуля, поэтому пропускатся не 2047, а 2047+1=2048 512-байтных секторов, всё сходится.

Хотя остаётся вопрос, почему именно 2048, 64 вполне хватило бы

Ну я выразился не так, сейчас тоже подумал. Раздел у меня с 2048 начинается, да.

>>Хотя остаётся вопрос, почему именно 2048, 64 вполне хватило бы

Точно такой же вопрос. Статью писал неизлечимый гуманитарий. У него внезапно появились 2048, хотя за секунду до этого было сказано о достаточности смещения в 64 сектора.

Меня смущяет, что там отсылка на vmfs и стораджи, а я ни сном ни духом. Срочно ищу документацию.

ЗЫ. Дебиан тоже что-то подотстал. И, [censured], на нетбуке с ssd у меня тоже раздел начинается с 63-го сектора.

Хорошо, но ведь раздел может начинаться и на первом секторе, разве нет? У меня лог\физ размер сектора 512 к, в нулевом MBR, а дельше разделы.

Если у тебя мало свободного места спереди, туда GRUB2 не влезет.

А, ну т.е. я могу например и с 3 -го сектора разбивать (одно время у меня так и было) и ничего страшного с точки зрения произовдительности не будет? А для тех, у кого 4096 им минимум с 64 сектора, так?

https://bbs.archlinux.org/viewtopic.php?pid=761740

Я бы оставил как делает анаконда.

Продолжаем раскопки.
1) из-за размера GPT (идёт на смену dos таблце разделов) первый раздел должен начинаться минимум с 34 сектора, тогда для выравнивания по 4k блокам пропускать нужно 40 секторов

2) В SSD размер блока - 128Кб (не 4k !! ), тогда пусть мы за унификацию и хотим при разметке не обращать внимания, hdd у нас или ssd.

Тогда начинаться раздел должен с 128Кб границы, т.е. пропускать нужно 256 секторов (256*512=128k).

Откуда взялась цифра в 8 раз больше - пока ищу

Я ей доверяю, просто любопытно разобраться до конца.

Больше найти ничего не могу. На уровне слухов и сплетен - везде пишут, что 2048 просто потому, что кто-то почесал левую пятку и решил выравнивать по границе 1 Mb

ЗЫ. http://rus-linux.net/nlib.php?name=/MyLDP/hard/WD10EARS_Linux.html

Сейчас вырву диск из домашнего рейда и буду тестировать

https://bbs.archlinux.org/viewtopic.php?pid=761740

Наверное, так и есть. Взяли границу в 256 секторов и умножили от фонаря на 8, чтобы было с запасом.

Там ссылка на тему, а в ней вот такое:

Former releases used the so called 62 block gap between the mbr (block 1) an the first partition block 63.

>region, if GPT you need a 1 MB BIOS Boot Partition (bios_grub flag in GNU Parted).

По-моему, бред. gpt boot partition - такой же раздел. И ему так же должен прешествовать gpt header в 33 сектора.

Там есть два варианта, как я понял. Либо спецраздел, либо граб просто лезет в gap (промежуток) между началом диска и первым разделом.

Старый граб влазил в мелкий промежуток.

Новый граб в мелкий промежуток не влазит, ему надо больше. Дальше гугли.

Да пофиг на спецраздел, границу в 1Mb это никак не объясняет.

adriano32 подсказал, что скорее всего это ИМХО микрософта, ставшее неофициальным стандартом

http://www.linux.org.ru/jump-message.jsp?msgid=5781895&cid=5782176

>Новый граб в мелкий промежуток не влазит, ему надо больше. Дальше гугли.

Гуглить придётся тебе. grub2 в случае dos-таблицы разделов так же прекрасно помещается в первые 63 сектора.

Ну вот от туда же из KB:

To resolve this issue, use the Diskpart.exe tool to create the disk partition and to specify a starting offset of 2,048 sectors (1 megabyte). A starting offset of 2,048 sectors covers most stripe unit size scenarios.

Т.е. оно логично только для raid дисков.

А 128k логично только для ssd.

Но чтобы не ломать голову, для всех дисков будет использоваться общее значение. Как стандарт

Ты погугли-погугли. grub2 собирает core.img исходя из твоей конфигурации (пруфлинк).

Он вполне может занимать 50 КиБ. (пруфлинк).

А теперь вспомним курс школьной математики. 512*63 < 50*1024, да.

1) «может» не означает «будет». В типовой конфигурации всё влезает в запасом. Нужно ещё постараться, чтобы выйти за рамки.

router@geek:~$ ls -lh /boot/grub/core.img

-rw-r--r-- 1 root root 24K Янв 11 11:35 /boot/grub/core.img

В любом случае, это нештатная ситуация, поэтому

Новый граб в мелкий промежуток не влазит

явный 4.2

2) мелкая придирка: не 512*63, а 512*62. В нулевой cектор (MBR) помещается только boot.img (в терминологии grub1 - stage1)

> 2) мелкая придирка: не 512*63, а 512*62

помещается в первые 63 сектора.

Да, зря я тебе на слово поверил.

«может» не означает «будет»

А теперь подумай. Установщикам (анаконде) разумно ставить такой размер, при котором (в обычных, неисключетельных ситуациях) «может» случиться ошибка установки граба?