Сравнение дисковой производительности файловой системы, расположенной в файле, изначально обречено на проигрыш по сравнению с производительностью файловой системы, расположенной на обычном накопителе. Вызвано это в первую очередь необходимостью двойного выделения блоков для размещения данных. Напомним, что файловый образ располагается на файловой системе. Соответственно рост файловой системы в файловом образе вызывает выделение блоков как в файле (дисковом образе), так и в файловой системе, на которой он расположен.
Однако такое сравнение имеет место быть, т.к. использование дисковых образов очень удобно для размещения разделов для виртуальных машин XEN или KVM. Выделение места на обычном диске в случае частых изменений, как правило, чревато сильной фрагментацией последнего. Рассмотрим на примере. Сначала нам потребовалось 3
и виртуальные машины с объемами диска: 8GB, 16GB, 24GB. Ответственный инженер создал 3-и раздела на физическом диске в 100GB следующую таблицу
/dev/sdx1 - 8GB
/dev/sdx2 - 16GB
/dev/sdx3 - 24GB
free 52Gb
Спустя месяц у нас появилась еще одна виртуальная машина с разделом в 24 GB, а второй раздел был удален вместе с занимаемой виртуальной машиной
/dev/sdx1 - 8GB
/dev/sdx2 - free
/dev/sdx3 - 24GB
/dev/sdx4 - 24GB
free 44GB
Таким образом мы пришли к ситуации, что между разделами 1 и 3-и есть 16GB свободного пространства, которое отделено от основной свободной области. И в общем случае не может быть использовано.
Вариантом решения может послужить создание LVM разделов поверх существующих физических. В этом случае спустя какое-то время мы приходим к ситуации, что у нас разрозненные по размеру физические разделы объединены в логические. Петрушка получается отменная.
Однако и в этой ситуация есть красивое решение. Изначально диск разбить на равного размера разделы. Например, 16GB. Объединяя через LVM нужно количество разделов в виртуальной машине, получаем требуемую дисковую область. Более продвинутый вариант, комбинированная разбивка. Например, 8GB...8GB, 16GB...16GB, 32GB...32GB, 64GB...
Теперь спускаемся на землю к нашим баранам. Альтернативным решением всех этих проблем кроется в создании образа файловой системы в файле, хранящемся на обычном разделе. Прежде чем использовать это решение давайте разберем какие минусы оно нам готовит по сравнение с очевидным большим плюсом (удобство использования).
В сравнении будет принимать, полюбившаяся всем, платформа SuperMicro SYS-1025W: 2x 2.83 GHz Quad Core Xeon (E5440), 32GB ECC RAM, 3Ware/LSI 9690SA-8I (512MB Memory, BBU). Из 8
ми накопителей SEAGATE ST9146802SS собран программный RAID10 c far размещением блоков:
cat /proc/mdstat
...
md3 : active raid10 sdh3[7] sdg3[6] sdf3[5] sde3[4] sdd3[3] sdc3[2] sdb3[1] sda3[0]
3950592 blocks 256K chunks 2 far-copies [8/8] [UUUUUUUU]
Для /dev/md3 используется файловая система ext3 с stride равным 64. Дисковый образ создан командой
dd if=/dev/zero of=128GB.img bs=1GB count=128
Файловая система в нём создана обычным вызовом
mkfs.ext3. Тестирование производится 5
и кратным прогоном
bonnie++ -x 5 -b.
CSV файлы для
обычной файловой системы и
дискового образа. Сводная таблица
+---------------------+-----------+---------+-----------+-------+
| | put_block | rewrite | get_block | seeks |
+---------------------+-----------+---------+-----------+-------+
| дисковый накопитель | 209176 | 111778 | 389820 | 772 |
+---------------------+-----------+---------+-----------+-------+
| дисковый образ | 124299 | 100490 | 391176 | 72 |
+---------------------+-----------+---------+-----------+-------+
После серого повествования немного рассуждений и выводов. Файловая система в дисковом образе почти в половину уступила файловой системе на дисковом накопителе в блочной записи. В данном виде теста bonnie++ активно выделяет блоки, а данный вид активности удваивается для дискового образа. Что полностью доказывает наши предположения в начале статьи. В rewrite оба претендента держатся на равных. Выделение блоков не требуется, а операции read(2)/write(2)/lseek(2) проходят достаточно прозрачно. В тесте get_block дисковый образ немного превзошел оппонента, сложно предположить как это получилось. Возможно, погрешность тестирования. В тесте seeks безоговорочная победа файловой системы на накопителе. Она практически растоптала оппонента вырвавшись вперед более чем на порядок.
Т.к. дисковый образ показал неплохую производительность на блочном чтении, его использование я бы порекомендовал для хранилищ больших файлов с превалирующим чтением и не критичным к времени записи операциям. Однозначно его использование противопоказано для баз данных и систем с активным доступом к случайным данным.
