LF №08(160), Август 2012: «Добавляем новый винчестер»
Учебник: Разбираемся с некогда простым добавлением жёсткого диска
С разрешения редакции журнала «LinuxFormat» предлагаю вашему вниманию статью Нейла Ботвика «Добавляем новый винчестер», вышедшую в «LinuxFormat» №08 (160) Август 2012.
Неважно, собрались вы добавить 2-терабайтный колосс или крошечный SSD: Нейл Ботвик поможет сделать всё правильно.
Когда-то добавить новый жёсткий диск было просто: требовалось лишь подключить его к компьютеру и создать разделы любимым инструментом командной строки (fdisk, cfdisk) или графическим (Gparted). Если вы меняли системный жёсткий диск, можно было загрузиться с дистрибутивного CD, и установщик системы выполнял разметку за вас. Теперь всё стало несколько сложнее: с виду разные накопители, как выясняется, демонстрируют сходные проблемы.
Большие жёсткие диски, порядка 2 ТБ, стали стоить вполне разумно, и вы можете захотеть просто воткнуть один такой в компьютер и начать им пользоваться — а в результате окажется, что производительность ниже, чем у вашего старого диска. Всему виной схема организации данных. Многие годы информация хранилась блоками по 512 байт (этот блок не связан с размером блока файловой системы). Диски становились больше, число блоков росло, и при 2 ТБ превысило максимальное значение, которое можно сохранить в 32-битном целом.
Тогда производители дисков перешли на 4 КБ блоки, в восемь раз больше; таким образом, проблема отложена до времён, когда один диск будет вмещать 16 ТБ. Это также позволило эффективнее хранить большие файлы, особенно с учётом того, что многие файловые системы, включая ext2/3/4, также используют блоки по 4 КБ. Это всё звучит неплохо до тех пор, пока вы не осознаете, что жёсткие диски вынуждены обеспечивать обратную совместимость с некой популярной ОС, притворяясь, что они по-прежнему оперируют блоками по 512 байт. Что в этом плохого? А то, что если вы начнёте файловую систему с блока, номер которого не кратен 8 (скажем, 63, что издревле было значением по умолчанию в Linux), каждый 4-КБ блок файловой системы будет храниться в двух физических блоках на диске, и каждое его чтение или запись превратится фактически в две операции ввода-вывода, что крайне негативно скажется на производительности (по ряду причин, увеличение объёма работы в два раза вызывает более чем двукратное падение скорости).