Я планирую использовать btrfs на массиве RAID6 объемом 50 ТБ и хочу включить сжатие lzo.
Это для настройки биоинформатики, когда выполняется много поисков в больших (1 ТБ - 20 ТБ) файлах. (Программа получает только небольшие фрагменты данных, разбросанных по файлу).
Меня беспокоит то, что я не понимаю, как выполняется поиск в сжатых файловых системах, таких как btrfs. Нужно ли сначала распаковывать файл от начала до искомой позиции? Это оказало бы огромное негативное влияние на мою установку.
Или более общий вопрос: масштабируется ли время поиска с размером файла так же, как в несжатой файловой системе, или становится хуже, например O (длина_файла)
В Интернете и здесь, в 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 <y. Бывают случаи, когда это может показаться другим, но это связано с другими неконтролируемыми факторами, такими как положение вращения на вращающемся диске. Или файлы X и Y открываются и читаются как потоки. Тогда все X до pos x должны быть прочитаны, и то же самое для Y. Но это не функция файловой системы. Команда fseek () непосредственно в разных местах файла покажет схожее время поиска. (Опять же положение на блюде зависит).
HTH.
Время случайного поиска будет примерно O (1), как и для несжатых файловых систем, но с оговоркой, что до 128 КиБ данных сжимаются вместе, поэтому для чтения только одного байта все данные в этом блоке 128 КБ должны будут читать и распаковывать. В зависимости от схемы доступа это может иметь несколько большое влияние на производительность, но вам необходимо сравнить это с вашим конкретным приложением и набором данных.
(Источник)