LINUX.ORG.RU

Чтение squashfs с диска медленнее чем из файла на разделе

 , , , ,


0

2

Как известно swap можно размещать не только в отдельном разделе но и в обычном файле на существующем разделе, но не рекомендуется по понятным причинам: дополнительная прослойка намекает на меньшую производительность.

Понадобилось заархивировать (и сжать) 1 ТБ диск (забитый где-то на треть) так, чтобы можно было сохранить простой доступ на чтение. Ничего лучше кроме squashfs не нашёл. Зато как раз вовремя подоспела поддержка zstd в ядре (пришлось разве что самому собрать свежий squashfs-tools). В итоге получилось, и быстрее, и без потери в размере (189 ГБ zstd против 193 ГБ gzip).

Сохранил образ с диска и создал раздел, на который через dd записал squashfs образ. Потом примонтировал и проверил на целостность: md5sum -b /mnt/sqfs/raw.hdd.img. Диск этот - внешний 2,5" USB2, так что максимум чтение 30 МБ/с (зато вне зависимости начало диска или конец). Получилось где-то 260 минут.

На всякий случай, решил сделать ext4 раздел минимального подходящего размера с -m 0 -T largefile4 и просто переписать образ в виде файла. Примонтировал, запустил проверку. Закончилась через... 160 минут. Не ожидал.

Выходит, или я что-то упустил, или мне выгоднее оставить тот ext4 раздел с единственным файлом-образом (разве что каждый раз при автомонтировании появляется предупреждение, что на нём осталось слишком мало места)?

★★★★★

вероятно это баг. как я понимаю, squashfs не предназначался для записи прямо вместо раздела. по zstd: не лучше ли тогда юзать btrfs? в него тоже недавно впилили.. а вот squashfs не вижу смысла юзать с чем-то другим, ктоме xz..

PexuOne ()

Можешь забить пустоту нулями, пробить дырки, и оставить как есть — эффективность будет на порядки выше, да и писать данные можно будет. 10 гигов разницы тебе погоды не сделают.

anonymous ()
Ответ на: комментарий от PexuOne

вероятно это баг. как я понимаю, squashfs не предназначался для записи прямо вместо раздела.

Я тестировал простейший последовательный доступ (md5sum). Разве что readahead кеш диска мог бы быть не включен / не использован по-умолчанию...

не лучше ли тогда юзать btrfs? в него тоже недавно впилили..

squashfs - это довольно стандартное решение, zstd - это уже несколько экспериментальный момент, но надеюсь что разархивирование не поломают. А вот btrfs лучше не буду трогать.

а вот squashfs не вижу смысла юзать с чем-то другим, ктоме xz..

Так я диск что через USB1, что напрямую по SATA смогу подключать, а скорость чтения будет где-то та же.

gag ★★★★★ ()
Ответ на: комментарий от anonymous

Можешь забить пустоту нулями

Это уже предварительно проделано.

пробить дырки, и оставить как есть — эффективность будет на порядки выше, да и писать данные можно будет. 10 гигов разницы тебе погоды не сделают.

Т.е. вытащить raw.hdd.img в виде файла (для чего понадобится 1 ТБ, но немного больше чем можно было бы выделить на разделе на имеющемся 1 ТБ диске, а другого терабайта нет сейчас под рукой) и продырявить его так, что останется только треть (т.е. около 300 ГБ). Потеря всё таки будет не 10, а 100 гигов.

gag ★★★★★ ()
Ответ на: комментарий от gag

Разве что readahead кеш диска мог бы быть не включен / не использован по-умолчанию...

hdparm -A /dev/disk/by-id/ata-TOSHIBA_...

/dev/disk/by-id/ata-TOSHIBA_...
 look-ahead    =  1 (on)

По крайней мере включён.

gag ★★★★★ ()
Ответ на: комментарий от gag

Останется ровно занятое простанство. Я не знаю может у тебя там одни текстовые файлы, я сжимал образы виртуалок с бинарными данными и разница была довольно незначительна. Накладные расходы перевесили потенциальную пользу стократ.

anonymous ()
Ответ на: комментарий от timdorohin

Ты что, храниш в сквоше не файлы с раздела, а образ раздела? Зачем!?

И даже не раздела, а всего диска с несколькими разделами.

Там на главном разделе ФС с не самой лучшей поддержкой в линуксе на данный момент.

gag ★★★★★ ()

Научный подход. Единственный эксперимент и масштабные выводы. Экстраполяция по одной точке. Интересно, хватит ли духу повторить эксперимент на 260 минут еще раз 5?

anonymous ()
Ответ на: комментарий от anonymous

Часто, проблема не в повторах. А в нахождении причин систематических погрешностей и их самих. Будет у него невыровненный раздел, или bad block, там - хоть 100 раз пусть повторит, а погрешность не денется никуда и не отыщется.

Deleted ()
Ответ на: комментарий от Deleted

Будет у него невыровненный раздел

Его нет, но даже если бы был, на чтение это не влияет (учитывая что размер блока намного превышает 4K).

или bad block,

Что squashfs-раздел, что ext4-раздел с squashfs-образом создавались в одной и той же области диска.

gag ★★★★★ ()
Последнее исправление: gag (всего исправлений: 1)
Ответ на: комментарий от Deleted

Для этого повторение эксперимента и нужно, чтоб понять, что не так с экспериментом или самим экспериментатором, который делает эксперименты на 260 минут

anonymous ()
Ответ на: комментарий от gag

Тебе рассказать как поставить более грамотный эксперимент? Может сам догадаешься? Начни с того, что 260 минут на эксперимент - это долговато. Разве нет? Потом можешь перейти к проверке частей: скорость чтения диска, файла с диска, файла с примонтированной фс, потраченное время, влючая системное на каждую операцию. Потом догадаешься играться с размерами блоков, методами сжатия, размера словарей для сжатия, степень сжатия и тд и тп. Этож сколько экспериментов по 260 минут?

anonymous ()
Ответ на: комментарий от anonymous

А, вот ты о чём.

скорость чтения диска

уже сообщал: в среднем 30 МБ/с

файла с диска

смотря какой регион файла считывается: с нулями - тогда скорость разархивирования нулей (сильно упирается в скорость чтения с диска) или данных (тогда не так сильно).

файла с примонтированной фс

да, это было бы самым показательным числом, но достаточно большого файла там, по-моему, нет, пришлось бы искать несколько не очень больших.

играться с размерами блоков, методами сжатия, размера словарей для сжатия, степень сжатия и тд и тп.

Но я всего-то хотел образ диска заархивировать. И так уже провозился значительно больше чем ожидал. Целую статью писать не планировал.

gag ★★★★★ ()
Ответ на: комментарий от gag

Ты ничего не понял.
Делаешь тестовый диск, закидываешь туда некоторое количество разделов с разнообразными файловыми системами, содержащими разноцветные файлы в разношерстных директориях. Посредством первых экспериментов выявляешь годность материала для дальнейших исследований, годность - включая по затратам времени.

смотря какой регион файла считывается: с нулями - тогда скорость разархивирования нулей (сильно упирается в скорость чтения с диска) или данных (тогда не так сильно).

Скорость распаковки исходных нулей, в правильных (де)компрессорах упирается в скорость записи распакованных нулей (и не только нулей, а одинаковых кусочков).

Но я всего-то хотел образ диска заархивировать. И так уже провозился значительно больше чем ожидал. Целую статью писать не планировал.

Так ты его сжал, но зачем-то начал дальше над результатом извращаться, сравнивая с чем-то другим в поисках виноватого. Тебе сжать надо или искать виноватого?

anonymous ()
Ответ на: комментарий от anonymous

Ну, да-да.

Так ты его сжал, но зачем-то начал дальше над результатом извращаться, сравнивая с чем-то другим в поисках виноватого. Тебе сжать надо или искать виноватого?

Запостив тут я надеялся, что после описания симптомов, может, найдётся кто-то, кто уже находил виноватого.

А так оставлю образ в файле на ext4 - и всё.

И другим для инфы: исключение из правила «меньше прослоек - больше производительность».

gag ★★★★★ ()
Ответ на: комментарий от gag

Запостив тут я надеялся, что после описания симптомов, может, найдётся кто-то, кто уже находил виноватого.

usb2, squashfs, образ диска, md5sum. Мало кто работает в таком окружении, еще меньше тех кто обращает на всякие симптомы в таком окружении.

И другим для инфы: исключение из правила «меньше прослоек - больше производительность».

Перешел на portage в squashfs, да еще через fuse, «производительность» выросла. Использую squashfuse_ll, без _ll - эталонный тормоз на тормозе(fuse) , а так на всего на 15% медленее ядерного.

anonymous ()
Ответ на: комментарий от gag

Попробовал, даже --sparse= не пришлось указывать. Вышло 315 ГБ. Потеря от ёмкости диска по сравнению со squashfs+zstd: 13,5% (126 ГБ от 932 ГБ).

Да и чтение+md5sum оказалось медленнее: почти 200 минут. Принципиальной разницы, что быстрее читается с диска: хорошо упакованные нули или sparse-дырки, я не вижу. Значит, было достаточно данных, которые хорошо утрамбовались и были распакованы без потери производительности (т.е. со скоростью не меньшей скорости чтения с диска).

gag ★★★★★ ()