К статье Ставим EARS, или пошагово цепляем диск с 4K-сектором
Приведу несколько тезисов:
- Каждый SATA/USB диск в линукс обозначается как sda, sdb, sdc, sdd и так далее, что кратко записывается регулярным выражением как sd[a-z]. Каждому новому диску присваивается новая буква.
- Каждый диск может иметь разделы (партиции). Если диск имеет всего один раздел, он обозначается как sda1 и так далее.
- Каждый диск с MBR может иметь всего 4 основных раздела. Обозначаются они как sd[a-z][1-4]. Если на диске необходимо создать более 4 разделов, то создают расширенный раздел (extended). В расширенном разделе можно натолкать сколько угодно разделов, и их нумерация начинается с 5.
- Когда запускаете fdisk или parted, нужно указывать имя родительского диска, например /dev/sda или /dev/sdc (но не имя раздела).
- Перед тем как разбивать, форматировать или проверять диск, нужно обязательно размонтировать все его разделы. Это можно сделать прямо из OSD попкорна через меню «Извлечь диск». Убедиться что никакой раздел не подмонтирован можно через команду mount без параметров.
- Если пользуетесь fdisk из моего пакета (Linux Term Utils), он уже сам предлагает выравненное значение сектора.
- Если форматируете большой диск в ext2 или ext3, лучше указать руками inode ratio, иначе по умолчанию на каждый терабайт тратится 14.5 ГБ места под иноды.
- Перед форматированием в ext2 или ext3 лучше сразу отключить резервацию места под root (ключ -m 0).
Уделю подробнее внимание inode ratio
По умолчанию, при форматировании в ext2/3 создается блок размером 4096 байт (block size). Каждый кластер (минимальная единица размера файла) занимает 16384 байт, что состоит из 4 блоков по 4096 байт. Каждый кластер описывается 1 статическим инодом. Размер каждого инода занимает 256 байт. Считаем:
- Любой файл/директория на диске описывается как минимум 1 инодом и занимает как минимум 16КБ.
- На каждый 1 ТБ дискового пространства уходит 14.5 ГБ под статические иноды. Терабайт — в данном случае это то что нам пихают продавцы дисков, а именно 1 000 000 000 000 байт. Делим это на 64 (inode ratio) и затем делим на честный гигабайт (1 073 741 824 байт), в итоге получается 14.55 ГБ на терабайтный диск или 29.1 ГБ на двухтерабайтный диск. Это место полностью недоступно для системы, оно уйдет под иноды.
Если на диске много больших файлов, куча инодов (и место на диске) пропадают впустую. Поэтому для медиабиблиотеки лучше использовать свое inode ratio.
Самый простой вариант — отдать под каждый inode кластер размером в 1МБ. При этом каждый файл на диске будет занимать минимум 1 МБ. Если на диске храним образы BD, это расточительно, поскольку там много мелких файлов.
На мой взгляд, для медиабиблиотеки оптимальный размер кластера будет 262144 байт, это означает что каждый inode будет описывать 64 блока по 4096 байт. При этом под inod-ы уйдет места ровно в 16 раз меньше и на каждый терабайт мы потеряем меньше 1 ГБ под иноды. Чтобы отформатировать диск с такими параметрами, нужно указать ключи
Для ext2:
Для ext3:
Так какие же преимущества перед inode, описывающим кластер в размером 16Kбайт и 256Кбайт?
А давайте посчитаем при самом худшем раскладе.
Предположим у вас на 2ТБ диске 100 образов BD. Больше — навряд-ли, образ BD занимает в среднем 20ГБ.
Если вы форматируете с inode_ratio по умолчанию, то вы теряете под иноды 29ГБ. Потерей на хвосты кластеров пренебрегаем.
Если вы форматируете с inode size = 262144, вы теряете под иноды 1.8ГБ.
Посчитаем потери под хвостами кластеров. Предположим в каждом образе BD находится по 100 мелких файлов. При самом худшем раскладе вы потеряете с каждого файла 1 кластер размером 262143 байт (пересечение 1 байт). Считаем потери:
100 хвостов * 262143 байт * 100 образов, получается 2 621 430 000 байт, что равно 2.44 ГБ.
29 ГБ против 4.2 ГБ (1.8 inode + 2.4 хвосты)
Выгода очевидна!
В реальной жизни условия будут еще мягче и потери еще меньше. Уже есть повод задуматься?
Реально, если диск предназначен для медиатеки, на котором много больших файлов, то конечно же кластер нужно делать больше, и выгода будет большой. Даже для BD образов. Про рипы и ремуксы и речи не идет, на них выгода будет колоссальной.
Но выгоды не будет, если на диске будет полно мелкоразмерных MP3-шек и подобной ботвы.
Это речь про Linux ext2/3/4.
NTFS и XFS не имеют таких проблем, так как полностью 64 битные и имеют динамическое распределение инодов.
Чтобы не быть голословным, и подтвердить теорию практикой, приведем пример нарезки диска WDC WD10EADS (включен в USB-хаб) на один раздел в Ext2, продемонстрировав прибыль от увеличения размера inode.
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
61054976 inodes, 244190636 blocks
0 blocks (0.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
7453 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 32 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
<em>##Затраченное время порядка 30 минут (это на USB-диске, не забываем)</em>
PCH-C200[~]mount /dev/sdf1 /share/55
PCH-C200[~]# df -h /dev/sdf1
Filesystem Size Used Available Use% Mounted on
/dev/sdf1 916.9G 71.6M <strong>916.8G</strong> 0% /opt/sybhttpd/localhost.drives/USB_DRIVE/55
PCH-C200[~]# umount /dev/sdf1
PCH-C200[~]# mkfs.ext2 -m 0 -i 262144 /dev/sdf1
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
3815936 inodes, 244190636 blocks
0 blocks (0.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
7453 block groups
32768 blocks per group, 32768 fragments per group
512 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 28 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
<em>##Затраченное время порядка 5 минут</em>
PCH-C200[~]# mount /dev/sdf1 /share/55
PCH-C200[~]# df -h /dev/sdf1
Filesystem Size Used Available Use% Mounted on
/dev/sdf1 930.5G 71.6M <strong>930.5G</strong> 0% /opt/sybhttpd/localhost.drives/USB_DRIVE/55
Итого, разница в свободном месте на одном и том же HDD при inode=256K 13.7 Гигабайт против inode по умолчанию
Для заинтересовавшихся строением файловой системы Ext2 всезда доступна Википедия: http://ru.wikipedia.org/wiki/Ext2
21 ноября 2010 г. в 18:29
Более внимательно исследовал fdisk (util-linux-ng 2.17.2), он предлагает выровненный только первый раздел и создает его с сектора 2048. Однако если цель разбить 4К-секторый диск на несколько разделов, то fdisk может предложить невыровненный номер сектора для следующих разделов, поэтому нужно руками корректировать начальный номер сектора (увеличивать его), чтобы он был кратен 8.
21 ноября 2010 г. в 19:00
И еще — он предлагает с 2048 только если нажать «c», т.е. не DOS-режим, который выплывает по-умолчанию, если этот HDD уже с DOS-совместимым MBR был записан.
Мне никаких идей умных в голову не пришло по автоматизации переформатирования скриптом, кроме как dd первого сектора на HDD с копии, а потом ресайзинга последнего раздела на весь размер HDD с parted.
Логично рассуждаю?
21 ноября 2010 г. в 18:53
По моим размышлениям, при большом размере кластера, скорость полной аллокации при использовании transmission также должна возрасти и очень значительно. Если это так, то можно не чураться большим кластером для торрента и поставить его 1048576, и чихать на потери, которые в хвостах кластеров будут, предполагая что маленьких файлов все равно будет не так много.
24 ноября 2010 г. в 08:03
2 Padavan
Наверно выберу время и попробую. Можете расписать последовательность команд для внутреннего диска С200 2.5″ (/dev/sdb у меня) на который поставлены штатным образом nmt приложения, чтобы сделать пользовательский раздел с кластером 1 мб? В момент работы fdisk затрутся и приложения linux utils
это не нарушит завершение операций fdisk ?
24 ноября 2010 г. в 09:41
1) Определяете через команду df имя раздела, которое используется на внутреннем SATA диске. Обычно оно выглядит так:
/dev/sda1 949.6M 70.1M 879.5M 7% /nmt
/dev/sda3 1.8G 32.1M 1.8G 2% /persistfs
/dev/sda4 70.1G 63.9G 6.2G 91% /opt/sybhttpd/localhost.drives/SATA_DISK
В данном случае требуемый раздел /dev/sda4
2) Останавливаете торрент (если запущен).
3) Размонтируете это раздел через OSD через кнопку ПДУ File. Проверяете командой mount, что раздел не смонтирован (его не должнобыть в списке).
4) Набираете команду
mkfs.ext3 -m 0 -i 262144 /dev/sda4
и ждете завершения процесса.
5) Перезагружаете попкорн. Вуаля.
Можно кластер сделать не 262144, а 524288 или 1048576, зависит от того, много ли будет у вас хранится мелких файлов на этом разделе. Если много, то лучше 262144.
fdisk совсем не требуется, диск у вас разбит уже.
24 ноября 2010 г. в 09:45
Забыл предупредить, что после форматирования вы потеряете все файлы на этом разделе, поэтому если вам там что-то нужно, сохраните данные. Там обычно установлены CSI приложения в папке /Apps, а также есть закачки торрента.
24 ноября 2010 г. в 09:54
Так как у вас на форматируемом диске находится Linux Term Utils, это приложение размонтируется, поэтому перед размонтированием диска скопируйте файл /share/Apps/LinuxUtils/e2fsprogs/sbin/mke2fs в /sbin, предварительно удалив там симлинк /sbin/mke2fs. Скопировать удобнее через mc.
24 ноября 2010 г. в 09:51
«Забыл предупредить, что после форматирования вы потеряете все файлы на этом разделе, поэтому если вам там что-то нужно, сохраните данные. Там обычно установлены CSI приложения в папке /Apps, а также есть закачки торрента.»
То что потеряю файлы в этом разделе, для меня очевидно. Не очевидно вот что: утилита (скрипт) mkfs.ext3 будет загружен из убиваемого раздела, в процессе работы скрипта, он ничего не захочет загрузить из уже убитого раздела? Процесс без сбоев пройдет?
24 ноября 2010 г. в 09:57
Уже ответил выше. После форматирования и перезагрузки переустановите Linux Term Utils и другие приложения что были установлены через CSI.
24 ноября 2010 г. в 10:14
«Так как у вас на форматируемом диске находится Linux Term Utils, это приложение размонтируется, поэтому перед размонтированием диска скопируйте файл /share/Apps/LinuxUtils/e2fsprogs/sbin/mke2fs в /sbin, предварительно удалив там симлинк /sbin/mke2fs. Скопировать удобнее через mc.»
А mkfs.ext3 — это скрипт? его так же копировать?
24 ноября 2010 г. в 10:23
pchuser, возьми флешку, накати Приложения на нее, а потом отформатишь хард — верни через визард Нормал-сетапом или указанием места расположения приложений
Это как «простой» выход
24 ноября 2010 г. в 12:53
mkfs.ext3 — это симлинк, он ссылается на mke2fs в этой же директории.
26 ноября 2010 г. в 17:26
2 Padavan не получилось
«3) Размонтируете это раздел через OSD через кнопку ПДУ File. Проверяете командой mount, что раздел не смонтирован (его не должнобыть в списке).»
после этого по команде df не видны все разделы этого диска
4) Набираете команду
mkfs.ext3 -m 0 -i 262144 /dev/sdb4
ругается что не может найти такое устройство
команда umount /dev/sdb4
и даже umount -f /dev/sdb4
ругается, что устройство занято
26 ноября 2010 г. в 19:58
Во, во, во… У меня тоже самое было. Голову «ломал» Уже не помню как решилось.
27 ноября 2010 г. в 08:43
Первое что приходит в голову — немедленно сойдите с диска!
Негоже пилить сук на котором сидишь. Обычно такое происходит когда какое-то приложение работает с этим разделом, или сам встаешь в каталог (через cd или в MC) на разделе, который хочешь отмаунтить.
Тушите лишние приложения при ручной работе с дисками.
27 ноября 2010 г. в 10:22
Если терминалом запущен SSH, это он держит диск, поскольку dropbear запускается с диска приложения. Надо бы его перенести в rootfs, он в принципе тонкий, 215 КБ, так что можно и в ОЗУ поместить. Telnet сейчас запускается с rootfs.
26 августа 2011 г. в 13:46
Странно, с первого раза мой пост исчез… Sorry если дважды.
Вопрос по поводу большого размера inode:
Не происходит ли при фрагментации файла (скажем 100 фрагментов) увеличение занятого места, т.е. перерасход
места ?
25 сентября 2011 г. в 01:58
Ребятки! А есть ли авторитетное или единое мнение насчет хранения блюреев? Папка с файлами или ISO?