Требуется внутренняя производительность файла в BTRFS со сжатием LZO
Я планирую использовать btrfs на массиве RAID6 емкостью 50 ТБ и хочу включить сжатие lzo.
Это для настройки биоинформатики, где выполняется много поиска в больших (1 ТБ - 20 ТБ) файлах. (Программа получает только небольшие фрагменты данных, разбросанных по файлу.)
Меня беспокоит то, что я не понимаю, как выполняется поиск в сжатых файловых системах, таких как btrfs. Нужно ли сначала распаковывать файл от начала до искомой позиции? Это оказало бы огромное негативное влияние на мою настройку.
Или более общий вопрос: масштабируется ли время поиска с размером файла так же, как в несжатой файловой системе, или становится хуже, например, O (file_length)
Время случайного поиска будет примерно O (1), как и для несжатых файловых систем, но с оговоркой, что до 128 КБ данных сжимаются вместе, чтобы прочитать только один байт, все данные в нем 128 Блок KiB нужно будет прочитать и распаковать. В зависимости от схемы доступа это может иметь несколько большое влияние на производительность, но вам необходимо сравнить это с вашим конкретным приложением и набором данных.
( Источник )
В Интернете и здесь, в Stackoverflow, есть много дезинформации о сжатии файловых систем. Сжатие файловой системы выполняется на уровне блоков (или на уровне фрагментов, в зависимости от устройства), а не на уровне абстракции файлов, поэтому якобы поиск аналогичен - поиск файлов выполняется в терминах блоков, а не в терминах сжатых битов. Это означает, что само сжатие не предоставляется программам пользовательского уровня. Так что вам не нужно думать об этом или беспокоиться об этом.
"Сверхпростой" способ визуализации: x / 0 - это блоки, группы блоков в файле. несжатые файлы и блоки: [xxx] [xxx] [xxx] [xxx] сжатые файлы и блоки: [xx] 0 [xx] 0 [xx] 0 [xx] 000 По правде говоря, это не совсем так, но inodes файлов будут указывать на сжатые блоки и прозрачно оставлять пространство, которое не нужно файлу.
В принципе, в настоящее время нет причин не включать fs-сжатие. За исключением нескольких редких случаев, производительность fs-сжатия строго лучше, чем несжатого чтения. Для биоинформатических данных, с которыми я также работал, вы иногда хотите максимизировать пропускную способность чтения, и сжатие достигнет этого - то есть скорость чтения несжатых данных будет превышать ограничения контроллера + интерфейса. (N сжатых битов в sata III / raid становится N * битов степени сжатия). Не обращайте внимания на чушь, которую люди говорят о задержках, замедлении работы процессора и т. Д. ЦП в 1000 раз быстрее, чем чтение с диска.
Для некоторых тестов производительности здесь: http://www.phoronix.com/scan.php?page=article&item=btrfs_lzo_2638&num=2
Еще одна путаница может возникнуть, если мы смешаем сжатие на уровне файлов (например, gzip или xz и т. Д.) С уровнем файловой системы сжатие. В этих случаях, да, поиск файла является недетерминированным, и абсолютные местоположения данных в файле не могут быть строго доступны без распаковки предыдущего байтового потока, чтобы найти смещения определения словаря в файле. Таким образом, при сжатии на уровне fs вы сохраняете поиск с потерей некоторой сжимаемости.
Кроме того, причина, по которой сжатие уровня блока / fs обычно (и исторически) отключено, заключается в том, что это может увеличить фрагментацию внутри файла, особенно с запись в середине файла. Для старых дисков или дисков с файлами базы данных сама фрагментация может привести к снижению производительности (это все еще верно для SSD, но из-за цикла перезаписи / стирания блоков, а не из-за линейно движущейся считывающей головки). Если это гигантский биоинформатический поток, то промежуточные записи могут не быть проблемой.
В общем, масштаб времени поиска зависит от расположения inode и файловой системы. Не размер файла. Например. если у вас есть два файла, большого размера X и большего размера Y, ни один из которых не умещается в пределах считывания диска и кеша и не может быть прочитан за одно чтение inode,тогда время достижения позиции x в X приблизительно равно времени достижения позиции y в Y, где x HTH.