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 раздел с единственным файлом-образом (разве что каждый раз при автомонтировании появляется предупреждение, что на нём осталось слишком мало места)?

★★★★★

2 раза перечитал и так ничего и не понял. Поздравляю, сегодня ты победил.

anonymous
()

вероятно это баг. как я понимаю, 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

ну типа доступ к сжатому файлу без распаковки. это вообще всё, что было понятно из поста, а ты даже в это не смог.

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

Я просто в такое извращение по-началу поверить не мог...

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

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

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

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

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

А не лучше данные достать? А то я тоже так qcow с нтфс подключал, не очень хорошо получилось (особенно запись удручает).

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

Specify --sparse=always to create a sparse DEST file whenever the SOURCE file contains a long enough sequence of zero bytes.

Хорошая дока: «long enough».

Ради бенчмарка можно попробовать.

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

Там HFS+, а на ней Time Machine. Там столько файлов (и hard ссылок), что любые операции длятся минутами.

gag ★★★★★
() автор топика

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

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

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

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

Второй раз повторял. Т.к. эксперимент длится не наносекунды и даже не пару минут, то тут сколько не повторяй, различий нет.

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

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

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

или bad block,

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

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

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

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

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

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

Да нормально, ему будет чем заняться в ближайший месяц. Зато эксперимент будет максимально правдоподобный (хоть и неэффективный).

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 ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.