Оценка потребления памяти в Линукс (RSS и VSZ)

 Оригинал: https://web.archive.org/web/20120520221529/http://emilics.com/blog/article/mconsumption.html

Примечание переводчика: статья написана в 2012 году, когда RSS считался так, как пишет автор. В настоящий момент в выводе программ вроде ps используется PSS, которая обозначается как RSS. Если вы запустите скрипт на питоне, ссылка на который есть в статье, то получите значение, которое совпадает с RSS в современной системе.

В статье рассказывается об объективном методе оценки потребления памяти процессом в Линукс. В Линукс имеется менеджер виртуальной памяти, поэтому определить, сколько памяти потребляет один процесс, не так просто, как многие думают. В статье объясняется, что означает каждый индикатор потребления памяти.

    Вывод для тех, кому некогда читать

Я считаю объективной метрику PSS(Proportional Set Size) для оценки потребления памяти, если ваша линукс-система её поддерживает. Функция на Питоне, приведённая ниже, возвращает PSS для процесса с заданным ID в кибибайтах (1 Kib=1024 байт). Если она не работает, то, вероятно, ваша операционная система не отображает PSS.

import sys, re

def pss_of_process(pid):
    with file('/proc/%s/smaps' % pid) as fp:
        return sum([int(x) for x in re.findall('^Pss:\s+(\d+)', fp.read(), re.M)])

Вот ссылка на скрипт pss.py, который выводит список процессов и значение PSS для них: https://web.archive.org/web/20130227090134/http://emilics.com/media/pub/pss.py
Чтобы увидеть значения PSS для всех запущенных в пространстве пользователя процессов, выполните команду:

% sudo python pss.py

Вывод команды (на машине переводчика):

admin       1116     934  /bin/sh /usr/bin/startx
admin       1160     909  sh /home/admin/wmaker.sh
messagebus   950     737  /usr/bin/dbus-daemon --system
admin       1146     549  /usr/bin/dbus-daemon --syslog --fork --print-pid 5 --print-address 7 --session
admin       3233     481  /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-
admin       1155     459  wmsystemtray
admin       1145     446  dbus-launch --exit-with-session /usr/bin/wmaker
root        1089     371  dhcpcd: [privileged proxy] wlan0 [ip4]
dhcpcd      3138     333  dhcpcd: wlan0 [ip4]
root        1063     318  /sbin/agetty 38400 tty3 linux

Программа распространяется под лицензией BSD.

     Аллегория, чтобы понять идею

В статье объясняется значение трёх индикаторов, которые можно использовать для определения размера потребляемой одним процессом памяти в Линукс. Это VSZ (Virtual Memory Size) - размер виртуальной памяти, RSS (Resident Set Size) - размер резидентной памяти, и PSS (Proportional Set Size) - пропорциональный размер резидентной памяти.

Хоть аналогия будет неточной, давайте рассмотрим следующий пример, чтобы понять смысл индикаторов: три человека живут в одной комнате. Будем считать, что каждый человек - это процесс, а стоимость проживания - потребление памяти. В этой аналогии потребление памяти одним процессом будет соответствовать расходам на оплату комнаты для одного человека.

У каждого жильца свой сотовый телефон, и расходы на сотовую связь они оплачивают отдельно. Все три индикатора -  VSZ, RSS, PSS, - будут учитывать расходы на сотовую связь для каждого индивидуально, здесь проблем нет.

Вместе с комнатой сдаётся гараж, который можно использовать, если за него заплатить. Но у всех троих нет машины, и они им не пользуются. Тем не менее, VSZ будет добавлять всю стоимость гаража каждому в расходы, даже если человек им не пользуется. То есть VSZ - это расходы на проживание, включая все доступные опции, независимо от их фактического потребления. RSS и PSS учитывают только фактические расходы и, соответственно, не будут учитывать стоимость неиспользуемого гаража.

Все трое пользуются одним шлюзом для интернета и кабельным телевидением, поэтому делят затраты между собой. В этом случае RSS будет добавлять полную стоимость интернета и TV каждому жильцу, даже если стоимость поделена между ними. RSS устроен так, чтобы подсчитывать расходы, будто они ни с кем не разделены.

PSS будет добавлять в оплату проживания каждому треть стоимости интернета и телевидения, поскольку счёт делится между всеми жильцами. Эта метрика более объективна, чем RSS, так как учитывает то, что расходы поделены.

Давайте немного усложним аналогию, чтобы понять ограничения для PSS. Один из жильцов много сидит в интернете, а телевизор смотрит мало, поэтому они договорились, что он оплачивает 50% стоимости интернета и 20% телевидения. PSS не учитывает подобные ситуации и просто делит затраты на интернет и телевидение поровну - каждому третью часть.

Я считаю, что PSS - наиболее объективная метрика, хотя у неё есть свои ограничения, и в некоторых ситуация RSS предпочтительней - в случае, если вы хотите узнать, сколько будете платить, если съедете с комнаты и будете жить одни.

    Управление виртуальной памятью

В старые добрые времена узнать количество потребляемой одним процессом памяти для операционных систем типа MS-DOS или µITRON было просто. Однако в современных системах всё сложнее, поскольку они снабжены менеджером виртуальной памяти, который даёт множество преимуществ, но при этом усложняет расчет используемой памяти для одного процесса.

Менеджер виртуальной памяти в Линукс имеет ряд важных функций, связанных с измерением потребления памяти. Прежде чем перейти к их объяснению, давайте посмотрим результат команды ps aux, которая выдаёт информацию о процессах (Прим. переводчика: это вывод с моей машины).


USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0   2480  1752 ?        Ss   12:26   0:00 init [3]
root         2  0.0  0.0      0     0 ?        S    12:26   0:00 [kthreadd]
root         3  0.0  0.0      0     0 ?        I<   12:26   0:00 [rcu_gp]
root         4  0.0  0.0      0     0 ?        I<   12:26   0:00 [rcu_par_gp]
root         5  0.0  0.0      0     0 ?        I<   12:26   0:00 [slub_flushwq]
root         6  0.0  0.0      0     0 ?        I<   12:26   0:00 [netns]
root         8  0.0  0.0      0     0 ?        I<   12:26   0:00 [kworker/0:0H-events_highpri]
root        10  0.0  0.0      0     0 ?        I<   12:26   0:00 [mm_percpu_wq]


В странице руководства man ps написано следующее:

RSS - объём резидентной памяти - памяти, которую использует процесс, не считая выгруженной в своп. Алиас rsz.

VSZ - объём виртуальной памяти процесса в кибибайтах. Device mapper на данный момент не учитывается, алиас vsz.

Какую метрику использовать: RSS или VSZ? Далее будет объяснено, как работают оба эти индикатора,  а также PSS (Proportional Set Size). Команда ps не отображает PSS, но его можно найти в файловой системе /proc.*
 *Примечание переводчика: конкретно в /proc/$pid/status, где оно называется теперь RSS.

Технические термины: 

Страница - блок памяти, которым оперирует менеджер памяти в Линукс. Как правило, её размер составляет 4096 байт.

Физическая память - реальная память - как правило, RAM, - которая имеется в компьютере.

Виртуальная память - память, выделяемая под процесс. Процесс считает, что у него своя собственная непрерывная память, изолированная от других процессов, независимо от объёма физической памяти компьютера и от того, сколько ещё процессов на неё претендуют. Страницы виртуальной памяти отображаются в физические страницы и, таким образом, процессы оперируют только виртуальной памятью.

    VSZ и Demand Paging

Использовать метрику vsz для измерения памяти, потребляемой процессом, не имеет особого смысла из-за функции Demand Paging - загрузка страниц в память при обращении к ним, - которая предотвращает ненужное потребление памяти.

Например, функционал текстового редактора emacs позволяет работать с XML-файлами. Однако, большую часть времени эта функция не используется, поэтому нет смысла загружать её в физическую память, если пользователю надо отредактировать обычный текст. Demand Paging не даёт загружать страницы, к которым процесс не обращается. Функция работает следующим образом: при запуске программы Линукс выделяет процессу виртуальную память, но не загружает в физическую память страницы, к которым она не обращается в данный момент. Когда программа вызывает функцию из виртуальной памяти, модуль управления памятью процессора - MMU - сообщает ОС, что страница не загружена. Тогда Линукс приостанавливает выполнение процесса, загружает страницу в физическую память, после чего снова запускает процесс. При этом процессу не нужно знать, что он был приостановлен - он просто полагает, что функция загружена в память, и использует её.

VSZ (virtual memory size) показывает размер всей виртуальной памяти процесса, независимо от того, загружены страницы в физическую память или нет. Таким образом, это не объективный показатель потребления памяти, включающий в себя фактически не используемые страницы.

     RSS (Resident Set Size) и разделяемые библиотеки

RSS показывает общее количество страниц процесса, загруженных в физическую память. Может показаться, что это и есть настоящий объём потребляемой процессом памяти, и что эта метрика лучше, чем VSZ, но всё не так просто из-за разделяемых (динамических) библиотек.

Библиотека - это модуль, который программы используют для реализации определённого функционала. Например, libpng.so занимается сжатием и распаковкой изображений в формате PNG, а libxml2.so - обработкой файлов XML. Чтобы программистам каждый раз не писать эти функции, можно пользоваться библиотеками, которые уже написаны.

Разделяемый объект - это библиотека, которой одновременно пользуются несколько программ или процессов. Пусть у нас запущено одновременно два процесса, которым требуется функционал библиотеки libxml2.so. Чтобы не загружать несколько раз одинаковые страницы памяти, Линукс загружает один экземпляр библиотеки в физическую память и отображает его в виртуальную память обоих процессов. Процессам неважно, используют ли они функцию совместно, так как они получают доступ к ней в своей виртуальной памяти. Разделяемые библиотеки позволяют не дублировать страницы в памяти.

А теперь вернёмся к примеру про emacs, который может работать с файлами в формате XML благодаря библиотеке libxml2.so. На этот раз пользователю на самом деле нужно открыть файл XML в emacs, поэтому emacs использует libxml2.so. Тем временем в фоне выполняются ещё два  процесса, использующие ту же библиотеку. Поскольку она разделяемая, Линукс загружает один её экземпляр в физическую память и отображает его в виртуальную память всех трёх процессов.

Если вы посмотрите метрику RSS для emacs, то в неё будут включены страницы libxml2.so. RSS не врёт, потому что emacs действительно её использует, но как насчёт двух других процессов, обращающихся к библиотеке? Если вы сложите RSS всех трёх процессов, то libxml2.so будет учтена три раза, хотя в физическую память загружен только один экземпляр.

Таким образом, RSS - это индикатор для случаев, когда процесс работает один и не использует никаких функций совместно с другими процессами. На практике, где разделяемые библиотеки используются совместно, RSS будет завышать показатель памяти, потребляемой одним процессом. Эту метрику можно использовать для оценки потребления памяти, но надо иметь  в виду данную особенность.

    PSS (Proportional Set Size)

Индикатор PSS используется для измерения объёма памяти, потребляемой одним процессом, который делит объём памяти, потребляемой страницами разделяемых объектов, поровну между процессами, которые их используют. RSS считает объём памяти следующим образом: если N процессов используют одну разделяемую библиотеку, то каждый процесс потребляет часть памяти этой библиотеки, равную 1/N.

Например, emasc и ещё два процесса совместно используют библиотеку libxml2.so. Так как процесса три, то каждый использует  1/3 объёма памяти, занимаемой libxml2.so.

Я считаю, что PSS - более объективный индикатор, чем RSS. Особенно он подходит для учёта памяти, потребляемой всей системой, а не каждым процессом в отдельности. Например, если вы разрабатываете систему со множеством процессов и служб и хотите оценить, сколько памяти надо установить в устройство, то PSS покажет более точный результат, чем RSS.





 

Борьба с техническим прогрессом - остановка парковки головок HDD Toshiba 2.5" HDD MQ01ABD

 Диск был куплен в РФ около года назад. Раньше парковка останавливалась из линукса просто: командой hdparm с параметрами -B 254 или, например, -S 253. На диске с контроллером SATA 2 пока так и есть, но прогресс не стоит на месте, и новые контроллеры стали умнее: они не дадут вам пользовать диск 10 лет и не чихать.

По умолчанию, как обычно, параметр -B был выставлен в 128. К счастью, контроллер его в принципе воспринимает, в отличие от -S, на который никак не реагирует. Но теперь ни 254, ни 252 не отключают парковку полностью - если не запущен браузер, головы паркуются каждые несколько минут. Чтобы от этого избавиться, я отредактировала crontab, заставив систему каждые полсекунды писать, а потом стирать файл - если интервал был больше половины секунды, оно не работало; без выставления hdparm -B 254 тоже не работало. Поначалу всё было нормально: головы перестали парковаться, smart ничего нового не выдавал. Но примерно через три месяца атрибут 5 (reallocated sector count) вдруг показал 24 вместо нуля. При этом pending sector был 0, а reallocated event count - 7. Я сразу запустила команду повторно, чтобы посмотреть, растёт ли атрибут, и он был уже 136. На форумах обычно предлагают выбрасывать такие диски в мусорку, но я уже знала, что контроллер там ё***тый, поэтому полезла в crontab и закомментировала свои художества. После этого атрибут сразу перестал расти: я провела тесты offline и long, все стоит на месте. Прошла пара недель, и ничего не изменилось: reallocated sector count 136; pending sector 0;  reallocated event count 7. Таким образом, скорее всего, дело не в поверхности, а в сраном контроллере.

В общем, остался только один выход: браузер постоянно запущен, причем не на пустой вкладке, чтобы на диск периодически что-то писалось. Так парковка всё равно происходит чаще, чем по-нормальному, но всё-таки не каждые 2 минуты.

UPD

Вот так теперь выглядит мой смарт, срок работы около полугода: 1576 переназначенных секторов, 119 reallocated event, при этом pending sector ноль. Одна бабка сказала, что тошиба, в отличие от WD, переназначает сектора не только при ошибках записи, но и чтения. У них, вроде как, есть таймаут, и, если операция чтения в него не укладывается, происходит переназначение. Почему pending sector count пустой, я не знаю - возможно, контроллер глюкавый. В общем, посмотрю, сколько эта хрень проработает (на полях VALUE и WORST пока не отражается, диск работает быстро и стабильно), но, честно говоря, желания покупать тошибу у меня больше нет.

Отзыв о Freebsd 14.2 - сравнение со Slackware 15.0 и Ghostbsd.

 У меня на Слаке стал отваливаться wi-fi (суппликант не проходил авторизацию, никакой секс не помогал), и я решила попробовать freebsd. Сразу скажу, что причина отвала, скорее всего, в битом образе: прежде чем я поставила систему на этот ноут, флешка долго валялась без подключения, и данные, вероятно, пострадали. Та же слака 15.0 на другом ноуте работает как часы.
Установка производилась на новый SSD ёмкостью 240 ГБ на два древних ноута: один HP с графической картой intel и таким же чипсетом, второй Asus с чипсетом и картой Nvidia.
 
В общем, сначала мне было влом ставить голую систему: у фряхи есть образ с графической оболочкой, но там написано, что он для оптического привода (для флешек у них образ memstick), и, кроме того, он больше 4 ГБ (они там все поохуели, блядь, извините), а моя флешка для систем ровно 4 гига. В общем, я сначала попробовала Ghostbsd. Там по умолчанию стоит Mate в качестве рабочего стола - размер образа около двух гигов, - файловая система zfs. Установщик там графический, мне он не понравился, ничего толком выбрать не даёт, - например, или разметка по умолчанию zfs, или сам разбивай, - в общем, параша. Сначала я ставила его на Compaq. Я выбрала разметку диска по умолчанию, там был один слайс на всё и просто пул под названием zroot, ну ещё своп и загрузочный раздел.

Всё поставилось, загрузилось, заработало. Zfs жрёт память как не в себя (UFS тоже жрёт больше, чем линуксовые ext, но меньше, чем это). В общем, перейду сразу к минусам:

1. Я не смогла поднять вайфай - проводная сеть работала, но если бы в ноуте не было соответствующего адаптера, я бы отсосала.
Я пыталась поднять через их менеджер (уже забыла, как он назывался, но не Wifimgr) и руками, но нет.

2. Там как-то по умолчанию ставится так, что ты вообще не видишь аккаунт рута. Я не пользуюсь sudo, только su, и некоторые команды почему-то не могла выполнить. Например, он не выполнял команды администрирования zfs

3. Я хотела добавить пользователя в какую-то группу, а команды pw, сука, просто нет в системе. Я не помню, пыталась ли я поставить её с помощью их менеджера pkg, но жопа у меня подгорела.

4. Я попыталась поставить дрова nvidia из их репозитория так, как было описано в руководстве, но обломалась: эти дрова оказались протухшие (я потом посмотрела: у них версия 2, а во фряхе уже 4), и после перезагрузки я увидела чёрный экран.

Я устанавливала систему на HP, но на Асусе она тоже работала. Правда, когда я попыталась загрузить модуль ядра acpi_asus, она сказала, что этот ноут не поддерживается.

В общем, возможно, что-то ещё меня напрягло, но вот этого мне хватило, чтобы скачать образ фряхи и записать его на флешку.


И вот я запустила bsdinstall сначала на Асусе с Нвидиа. Но она начала громко ругаться: CAM status, CRC Error - короче, ругалась на Sata. Я даже звонила в сервисный центр, обосравшись кирпичами, но мне сказали, что вероятность отвала контроллера Сата почти нулевая: на его веку, говорит, такого не было. Честно говоря, я подумала на диск, но в ноуте с интеловским чипсетом всё прошло нормально.

Установщик очень удобный и интуитивный. Например, когда выбираешь временную зону, сначала появляется меню с континентами, потом - странами, а потом уже города, и не приходится мотать до посинения, чтобы найти свою зону, как в Слаке. Есть варианты разметки диска: дефолт с UFS, дефолт с ZFS, guided partitioning с UFS и руками. При этом, если выбрать guided, можно поставить на раздел диска, не сильно напрягаясь. Я выбрала zfs, так как она, вроде бы, оптимизирована под SSD - там есть Trim, информация размазывается по диску равномерно и всё такое - ну так написано в руководствах. Установщик предложил по умолчанию сделать блок 4 К (ashift 12).

Вот вывод команды zfs list после установки:
    
zroot               12.2G   201G    96K  /zroot
zroot/ROOT          8.55G   201G    96K  none
zroot/ROOT/default  8.55G   201G  8.55G  /
zroot/home          3.61G   201G    96K  /home
zroot/home/admin    3.61G   201G  3.61G  /home/admin
zroot/tmp            860K   201G   860K  /tmp
zroot/usr            288K   201G    96K  /usr
zroot/usr/ports       96K   201G    96K  /usr/ports
zroot/usr/src         96K   201G    96K  /usr/src
zroot/var            744K   201G    96K  /var
zroot/var/audit       96K   201G    96K  /var/audit
zroot/var/crash       96K   201G    96K  /var/crash
zroot/var/log        240K   201G   240K  /var/log
zroot/var/mail       120K   201G   120K  /var/mail
zroot/var/tmp         96K   201G    96K  /var/tmp

В общем, всё поставилось, я установила иксы, потом драйверы для видеокарты. Ну сначала я настроила регулирование частоты процессора и всё такое, но это всё есть в хэндбуке - я просто делала, как там написано. Попробовала набрать startx, и там если не установлен десктоп, то запускается уродский twm. Чтобы из него выйти, надо просто перейти в консоль (Alt+Ctrl+F1) и там нажать Ctrl+c. В общем, я накатила свой любимый fluxbox, запустила его (командой "startx /usr/local/bin/startfluxbox" - во фряхе команды пользователя и их конфиги хранятся в /usr/local), и он заработал. Скажу больше: в Слаке если выбирать темы для флакса, он иногда вылетал после переключения стиля, а здесь я заодно поставила темы - все стили с сайта tenr.de здесь есть в качестве пакета - и долго их дёргала (окно со списком получилось на весь экран - 15,6 дюймов, - и ещё пришлось прокручивать), и, хотя индикатор gkrellm скакал из стороны в сторону, ничего не вылетало.

Также я установила шрифты googlefonts. Настройка шрифтов есть в хендбуке, но могу сказать, что freetype здесь не такой, как в слаке - шрифты выглядят лучше.

Разнообразие программного обеспечения меня полностью устроило: даже бинарных пакетов дофига, а ещё есть порты, причём установка из портов тоже очень простая. Есть браузер Librewolf, которого нет в репозиториях слаки, но зато в слаке есть wps office бинарный, а здесь он только в портах - правда, во фре есть апач опенофис. Есть pipewire, да, в прнципе, всё необходимое есть в бинарном виде. Нет redshift-gtk, но просто redshift работает. То, что я установила, работает стабильно.

Потребление памяти: на старте fluxbox в слаке отжирал где-то 190 МБ по показаниям команды free в терминале sakura. Здесь сразу после запуска то же самое потребляет больше 800 метров по показаниям vmstat - команды free здесь нет. Сейчас у меня запущен терминал, gvim и librewolf c 12  вкладками, и из 3856 M свободы 1666 - так показывает индикатор в gkrellm.

Беспроводную сеть подняла с помощью wpa_cli без всяких плясок с бубном.

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

А теперь ложка дёгтя: кулер постоянно молотит на высоких оборотах. На форуме пишут, что во фряхе нет управления оборотами вентилятора, которое реализовано в линуксе в lm-sensors.

Мои впечатления: честно говоря, если бы не орущий кулер, я бы вообще не думала, оставить или поменять обратно на слаку. Freebsd 14.2 - огонь.

Происхождение выравнивания границ разделов жёсткого диска

оригинал: http://jdebp.info./FGA/disc-partition-alignment.html
 

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

    Заблуждения о выравнивании по границам дорожек

На первый взгляд, идея о том, что разделы на диске должны быть выровнены по границам цилиндров выглядит абсурдной. Миллионы людей пользовались дисками, на которых первый основной раздел начинался с нулевой дорожки, первого сектора и первой головки, без каких-либо негативных последствий для различных операционных систем, начиная c MS_DOS, затем Windows-NT и заканчивая OS/2. В конце концов, это были значения по умолчанию для утилит fdisk и Disk Manager в течение почти двадцати лет. Максимум утилиты могли потребовать выравнивания внутри дорожек, т.е. чтобы все разделы начинались с первого сектора (помните, что сектора нумеруются с единицы) на любой дорожке.

Но даже этого не было: ни одна операционная система никогда не предъявляла таких требований. Даже MS-DOS прекрасно работала с дисками, разделы которых начинались не с первого сектора. Такие требования выдвигали только утилиты для разбиения дисков. В некотором смысле это был порочный круг: утилиты для работы с диском предъявляли требования к выравниванию разделов, потому что их авторы думали, что того требует система. Но люди думали, что такое требование существует в системе, только потому, что его навязывали утилиты типа fdisk. Умозаключение выглядело так: раз утилиты накладывают такие ограничения, значит, на утилиты их накладывает сама система. Но на самом деле операционные системы ничего подобного не требовали.

Так или иначе, идея выравнивания дорожек безумна. Она не имеет смысла, поскольку это не приводит к выравниванию разделов по каким-либо допустимым границами на самом устройстве. Вы не получите выигрыша в производительности или каких-либо других преимуществ, так как разделы не будут выровнены по границам физических дорожек, если их выровнять по тем дорожкам, которые видят программы.

▪ "Дорожки", которое системное ПО видит на уровне регистра команд контроллера интерфейса ATA, не совпадают с реальными дорожками на поверхности диска с тех пор, как появилась ZBR (зональная побитовая запись). На самом деле дорожки на дисках с ZBR имеют разную физическую длину, хотя через старый командный интерфейс с адресацией цилиндр+головка+сектор на дисках ATA они представлялись программам одинаковыми.

▪ В отличие от контроллеров ATA, управляющий интерфейс SCSI всегда оперировал логическими адресами блоков, а не кортежами цилиндр+головка+сектор (CHS). Для контроллеров SCSI с самого начала была неприменима идея о том, что системное ПО обязано различать границы физических дорожек. Вообще-то разработчики контроллеров интерфейса SCSI для персональных компьютеров вынуждены были изобретать геометрию диска, беря её с потолка, ради прошивок PC/AT и PC98,  а также операционных систем, которые ожидали, что контроллеры интерфейса дисков будут оперировать геометрией CHS.

В 2008 г. Микрософт с большой помпой наконец искоренили эту совершенно бесполезную и бессмысленную идею из диспетчера дисков Windows NT (т.е. в релизах Windows Vista Service Pack 1 и Windows Server 2008). До этого, начиная с 2003 года, администраторам Exchange server и Microsoft SQL Server рекомендовалось использовать diskpart и устанавливать границы разделов кратными 4 кибибайтам из соображений улучшения производительности. Хотя некоторые из этих соображений были основаны на ложной посылке, что границы дорожек, которые видят программы, совпадают с физическими границами, тем не менее, в свете более поздней разработки оборудования, они дали ожидаемый результат.

Linux отстал от Windows, и по состоянию на 2011 год утилита fdisk продолжала жаловаться на то, что разделы не выровнены по границам дорожек. Поэтому настоятельно рекомендуется не пользоваться fdisk для разметки, заменив её более современными инструментами, такими как gdisk Рода Смита, у которого также есть преимущество в виде поддержки схемы разметки дисков EFI.

    Выравнивание границ кратно 4 KiB

Правило выравнивания границ разделов дисков, отражающее реальные физические границы, существует - это правило выравнивания  по границам 4 KiB, но оно применимо не ко всем моделям жестких дисков.

В некоторых моделях внутренний размер сектора был увеличен с 0.5 Kib до 4 Kib (физический сектор). Однако на уровне контроллера интерфейса, через который системное ПО общается с диском, размер сектора остался 0.5 Kib. Такие диски называются 512-байтовыми эмуляционными носителями. При этом предполагается, что будут и диски без эмуляции, у которых размер логического сектора также будет равен 4 KiB. Но, поскольку на данный момент очень немногие операционные системы поддерживают размер сектора, не равный 512 байтам, на уровне стандартных команд ATA/SCSI, то и пользователей таких носителей немного, и они не представляют большого потребительского рынка для производителей жестких дисков.

512-байтовые эмуляционные диски работают следующим образом: каждый раз, когда операционная система или прошивка считывает 0.5 KiB, само устройство считывает 4 KiB, делит это число на восемь и передаёт ОС или прошивке результат деления. Когда система/прошивка записывают сектор 0.5 KiB, диск фактически считывает весь физический сектор 4 KiB, модифицирует данные на его восьмой части и записывает весь сектор 4 KiB.

Может показаться, что это сильно снижает производительность, так как по сути каждая операция ввода-вывода оперирует размером данных в восемь раз больше видимого размера. К счастью, существует способ скрыть эти потери производительности: многие операционные системы всё равно предпочитают выполнять основную часть операций ввода-вывода над блоками, размеры которых кратны 4 KiB. Например, вся подкачка страниц на системах архитектуры x86 выполняется блоками, кратными 4 KiB. Кроме того, многие операционные системы, включая Windows NT и Solaris, используют механизм подкачки для обычного файлового ввода-вывода. Таким образом, обычно операционная система за одну операцию ввода-вывода считывает и записывает блоки, кратные восьми секторам размера 0.5 KiB.

Поэтому нужно, чтобы эти блоки непрерывно следовали друг за другом, и их границы совпадали с границами физических секторов диска, размер которых 4 KiB. "Естественные" границы блоков файловой системы должны совпадать со скрытыми границами секторов внутри диска. Восемь секторов по 0.5 KiB, которыми оперируют команды системы, не должны растягиваться на два или более физических сектора по 4 KiB - они должны составлять ровно один сектор и внутри этого сектора располагаться в правильном порядке.

Стоит заметить, что некоторые пользователи, измерившие падение производительности, вызванное тем, что разделы на 512-эмуляционных дисках не были выровнены по границе 4 KiB, с удивлением обнаружили, что производительность снизилась довольно существенно. Забавно, что цифры, которые они получили, были меньше, чем те восемь раз, которые теоретически должны возникнуть из-за того, что каждый запрос к 0.5 KiB превращается в запрос к 4 KiB, так что они наоборот должны были удивиться тому, насколько малым оказалось это снижение. Причиной того, что на практике производительность падает не так сильно, является кластеризация, как её принято называть в мире BSD - по крайней мере, в контексте подкачки при операциях ввода-вывода. При кластеризации несколько отдельных запросов на чтение/запись к смежным блокам диска объединяются в один, охватывающий все блоки в одной команде ввода-вывода, передаваемой устройству хранения данных. Это позволяет снизить количество обращений контроллера к секторам по 4 KiB и таким образом снижает накладные расходы.

Выравнивание по границам, кратным 4 KiB, достигается тремя способами:

    ▪ Выравнивание границ разделов по 4 KiB относительно начала диска: номер сектора начала и конца каждого раздела представляет собой целое число, кратное 4 KiB от начала диска.
    ▪ Выравнивание структур данных внутри тома по границам 4 KiB относительно начала раздела. Если формат тома использует концепцию зон (групп цилиндров и т.п.), как это бывает на томах с файловыми системами UFS или Ext2/3/4, эти зоны должны иметь целочисленный размер, кратный 4 KiB. Файловые системы FAT и NTFS не оперируют зонами, но при форматировании раздела в FAT общий размер файловых таблиц и зарезервированных секторов в начале тома должен быть целым и кратным 4 KiB, так чтобы кластеры с данными, следующие за ними, также были выровнены по границам, кратным 4 KiB.
    ▪ Целочисленный размер кластера файловой системы - логической единицы хранения данных, - кратный 4KiB.

На самом деле, как подметил Род Смит в своей статье ( http://rodsbooks.com./gdisk/advice.html#alignment), утилиты разметки дисков от Microsoft в настоящее время (2011 год) по умолчанию выравнивают границы разделов кратно 1MiB, что не имеет под собой никаких оснований. Времена, когда 1 Mib можно было рассматривать как (32 сектора) х (64 головки), давно прошли. Хотя по причинам, описанным выше, такой подход не имел смысла даже в то время, поскольку эта геометрия не соответствовала физической геометрии самого диска. Единственная причина использования для выравнивания размера 1 MiB вместо 4 KiB, который действительно соответствует физическому размеру сектора внутри диска, заключается в том, что при таком размере утилиты, отображающие положение и размер дисковых разделов в Мебибайтах, показывают целые числа. Иными словами, измерение границ и размеров разделов в единицах по 4 KiB оказалось излишне точным для пользователей, которые обычно не работают с разделами меньше Гибибайта при разметке диска.

    Выравнивание разделов на дисках, размеченных старыми утилитами

К сожалению, версии утилит fdisk и Disk Msnsger от Microsoft, которые были до 2008 года, а также текущая версия fdisk в линукс (текущая - это на 2011 год) по умолчанию не выравнивали границы разделов кратно 4 KiB по той простой причине, что (фальшивая) геометрия, которую использовало большинство дисков (размером больше 7,87GB, разумеется) предполагала, что на дорожке 63 сектора. Поэтому те старые глупые утилиты выравнивали разделы кратно шестидесяти трём секторам. Они начинали первый основной раздел с нулевого цилиндра, первой головки, первого сектора, а номер логического блока диска был 63, и весь раздел выравнивался по нечётному номеру сектора.

Таким образом, диски, размеченные старыми версиями утилит, надо переразбить, скорректировав размеры разделов. Границы разделов нужно сдвинуть в большую или меньшую сторону, так чтобы они начинались с целых чисел, кратных 4 KiB или  1 MiB. Если они были выровнены с учётом того, что на дорожке 63 сектора, то обычно между разделами или в начале/конце диска, если диск разбит с таблицей MBR, есть свободное место, чтобы выровнять разделы кратно 4 KiB. Это довольно длительный процесс, так как надо считать, а затем записать данные с каждого сектора на всех разделах, границы которых будут сдвигаться.